ということで、リーダブルコードの定石として使えそうなものを章ごとに抽出。
対象者はリーダブルコードの読者です。
弊記事を通して、何度も定石を思い出しリーダブルコードを読みなおし、自分の肉としてください。
（ただし、これらに囚われすぎず、プロダクトが動くのが第一！！というのが本音なのは内緒）
なお、チェックリストは既出でした
「リーダブルコード適用 チェックリスト」を作ってみました
が、弊記事は、より本書の内容に踏み込んでいます。
では行きましょう。（自己満自己理解のための、あうとぷ記事です...
1章 理解しやすいコード
- コードは理解しやすく
- コードは他人が最短時間で理解できるように書く
2章 名前に情報を詰め込む
-
明確な単語を選ぶ
- Getではなく、状況に応じてFetchやDownload
- tmpやretvalなどの汎用的な名前を避ける
- retvalという名前には情報がない。変数の値を表すような名前を使う
- tmpという名前は、生存期間が短くて、一時的な補完が最も大切な変数にだけ使う
- tmp・it・retvalのような汎用的な名前を使うときは、それ相応の理由を用意
-
具体的な名前を使って、物事を詳細に説明する
- ServerCanStart() より CanListenOnPort() のほうが明確
-
変数名に大切な情報を追加する
- ミリ秒を表す変数名には、後ろに_msをつける。これからエスケープが必要な変数名には、前にraw_をつける
-
スコープの大きな変数には長い名前を付ける
- スコープが数画面に及ぶ変数に1～2文字の短い暗号めいた名前を付けない。短い名前はスコープが数行の変数につける
-
大文字やアンダースコアなどに意味を含める
- クラスのメンバ変数にアンダースコアを付けて、ローカル変数と区別する
3章 誤解されない名前
- 名前が「ほかの意味と間違えられることはないだろうか」と何度も自問自答する
- 上下の限界値を決めるときは名前の前にmax_やmin_
- 包含的範囲ではfirstやlast
- 包含/排他的範囲ではbeginとend
- ブール値への名前付けではisやhasを使い、否定形を避ける
- ユーザーの期待に注意する
- get()やsize()には軽量なメソッドが期待される
- 複数の名前を検討する
4章 美しさ
- 読み手が慣れているパターンと一貫性のあるレイアウトを使う
- コードの列を整理して概要を把握しやすく
- 一貫性のあるスタイルは「正しい」スタイルよりも大切
- 似ているコードは似ているように見せる
- 意味のある順番を選んで、常にその順番を守る
- 関連するコードをまとめてブロックにする
- 複数コードブロックで同じようなこと→シルエットも同じにそろえる
- 空行を使って大きなブロックを論理的な「段落」に分ける
5章 コメントすべきことを知る
- コメントすべきで「ない」こと
- コードからすぐに抽出できること
- ひどいコードを補う →コメントを書くのではなくコードを修正
- 記録すべき自分の考え
- なぜ他のやり方でなく、そうするのか
- コードの欠陥をTODO:やXXX:などの記法で示す
- 定数の値にまつわる**「背景」**
-
読み手の立場で考えて生み出すコメント
- 質問されそうなこと
- ハマりそうな罠の告知
- ファイルやクラスの全体像
- コードブロックの概要
6章 コメントは正確で簡潔に
- コメントは領域に対する情報の比率を高くする
- 曖昧代名詞を避ける
- 複数可能性があるものに、指示代名詞を避ける
- ブラッシュアップ歯切れ悪い文章
- 関数動作を正確に
- 入出力のコーナーケースに実例の選定
- コードの意図は、詳細レベルではなく高レベルで
- 「名前付き引数」コメの使用
- 情報密度の高い言葉
7章 ループとロジックの単純化
- 条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く
-
条件は肯定形で
- if(!debug)よりif(debug)
- 単純な条件を先に書く
- 関心を引く条件や目立つ条件を先に書く
- 行数を短くするよりも、他人が理解するのにかかる時間を短くさせる
- 基本的にはif/elseを使う。三項演算子はそれによって簡潔になるときにだけ使う
- do/whileループを避ける
- 関数から早く返す
- 基本的にgotoは使わない
- ネストを浅く
- 変更するときはコードを新鮮な目で見る。一歩座がって全体を見る
- ループ内部のネストを削除
8章 巨大な式を分割する
- 巨大な式は飲み込みやすい大きさに分割
- 説明変数の導入
- 要約変数の導入
- ド・モルガンを使う
- 「頭がいい」コードに注意。後で他人が読む際分かりにくくなる
9章 変数を削除する
- 邪魔な変数を削除
- 中間結果の変数を削除
- 変数のスコープをできるだけ小さく
- 変数を操作する場所を増やさない
- 一度だけ書き込む変数を使う
10章 無関係の下位問題を抽出する
- 関数やコードブロックを見て**「このコードの高レベルの目標」を自問**
- コードの各行に対して「高レベルの目標に直接的に効果があるか、無関係の下位問題を解決しているのか」を自問
- 無関係の下位問題を解決しているコードが相当量あれば、抽出して別関数にする
11章 一度に一つのことを
- コードは1つずつタスクを行うようにする
- コードが行っている「タスク」をすべて列挙
- タスクをできるだけ異なる関数に分割
12章 コードに思いを込める
- ロジックを明確に説明する
- ライブラリを知る
- 解決策を言葉で説明する
- 手法を再帰的に適用する
- 問題を声に出して説明してみる
13章 短いコードを書く
- 最も読みやすいコードは何も書かれていないコード
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない
- 最も簡単に問題を解決できるような要求を考える
- 定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しむ
14章 テストと読みやすさ
- テストのトップレベルはできるだけ簡潔に。入出力のテストはコード1行で記述が理想
- テストが失敗したらバグの発見や修正がしやすいエラーメッセージを表示
- 安心してテストの追加や変更ができるように、テストコードを読みやすく
- テスト関数に説明的な名前をつけ、何をしているか明確に
- コードを完全にテストする最も単純な入力値の組み合わせを選択
- テストには最もキレイで単純な値を選ぶ