1章 理解しやすいコード
「鍵となる考え」→コードは理解しやすくなければいけない。コードは他の人が最短時間で理解できるように書かなければいけない。
2章 名前に情報を詰め込む
「鍵となる考え」→名前の情報を詰め込む。気取った言い回しよりも明確で正確な方がいい。
- 明確な単語を選ぶ
- tmpやretvalなどの汎用的な名前を避ける
- 具体的な名前を使って、物事を詳細に説明する
- 変数名に大切な情報を追加する
- スコープの大きな変数には長い名前をつける
- 大文字やアンダースコアなどに意味を含める
3章 誤解されない名前
「鍵となる考え」→名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答をする。
上下の限界値→max_,min_
包含的範囲→first,last
包含/排他的範囲→begin,end
ブール値→is,has disable_ssl(×)
4章 美しさ
「鍵となる考え」→一貫性のあるスタイルは「正しい」スタイルよりも大切だ。
- 複数のコードブロックで同じことををしていたら、シルエットも同じようなものにする
- コードの「列」を整理すれば、概要が把握しやすくなる
- ある場所でA,B,Cのように並んでいたものを、他の場所でB,C,Aのように並べてはいけない
- 空行を使って大きなブロックを論理的な「段落」に分ける
5章 コメントすべきことを知る
「鍵となる考え」→コメントの目的は、書き手の意図を読み手に知らせることである。コードからすぐわかることをコメントに書かない。
コメントすべきでは「ない」こと:
- コードからすぐに抽出できること
- ひどいコード(例えば、ひどい名前の関数)を補う「補助的なコメント」。コメントを書くのではなくコードを修正する
記録すべき自分の考え:
- なぜコードが他のやり方ではなくこうなっているのか
- コードの欠陥をTODO:やXXX:などの記法を使って示す
- 定数の値にまつわる「背景」
読み手の立場になって考える:
- コードを読んだ人が「えっ？」と思うところを予想してコメントをつける
- 平均的な読み手が驚くような動作は文書化しておく
- ファイルやクラスには「全体像」のコメントを書く
- 読み手が細部にとらわれないように、コードブロックにコメントをつけて概要をまとめる
6章 コメントは正確で簡潔に
「鍵となる考え方」→コメントは領域に対する情報の比率が高くなければいけない。
- 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける
- 関数の動作はできるだけ正確に説明する
- コメントに含める入出力の実例を慎重に選ぶ
- コードの意図は、詳細レベルではなく、高レベルで記述する
- よくわからない引数にがインラインコメントを使う
- 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
7章 制御フローを読みやすくする
「鍵となる考え」→条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないようにする。行数を短くするよりも、他の人が理解するのにかかる時間を短くする。基本的にはif/elseを使おう。三項演算子はそれによって簡潔になるときにだけ
使おう。変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る。
- 比較を書くときには、変化する値を左に、より安定した値を右に配置する
- if/else文のブロックは適切に並び替える
- 三項演算子,do/whileループ,gotoなどのプログラミング構成要素を使うと、コードが読みにくくなることが多い
- 深いネストを避けるには「直線的」なコードを選択する
- 早めに返してあげると、ネストを削除したりコードをクリーンにしたりできる。特に、ガード節が便利だ
8章 巨大な式を分割する
「鍵となる考え」→巨大な式は飲み込みやすい大きさに分割する。「頭がいい」コードに気を付ける。あとで他の人が読むときにわかりにくくなる。
巨大な式を分割するのに最も簡単な方法は「説明変数」を導入することだ。
- 巨大な式を分割できる
- 簡潔な名前で式を説明することで、コードを文書化できる
- コードの主要な「概念」を読み手が認識しやすくなる
からである。
9章 変数と読みやすさ
「鍵となる考え」→変数のことが見えるコード行数をできるだけ減らす。変数を操作する場所が増えると、現在地の判断が難しくなる。
- 邪魔な変数を排除する
- 変数のスコープをできるだけ小さくする
- 1度だけ書き込む変数を使う
10章 無関係の下位問題を抽出する
プロジェクト固有のコードから汎用コードを分離する。
11章 一度に1つのことを
「鍵となる考え」→コードは1つずつタスクを行うようにしなければならない。
12章 コードに思いを込める
1、コードの動作を簡単な言葉で同僚にもわかるように説明する
2、その説明のなかで使っているキーワードやフレーズに注目する
3、その説明に合わせてコードを書く
13章 短いコードを書く
「鍵となる考え方」→最も読みやすいコードは、何も書かれていないコードだ。
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない
- 最も簡単に問題も解決できるような要求を考える
- 定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく
14章 テストと読みやすさ
「鍵となる考え」→他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。コードを完全にテストする最も単純な入力値の組み合わせを選択しなければならない。
- テストのトップレベルはできるだけ簡潔にする。入出力のテストはコード1行で記述できるといい
- テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する
- テストに有効な最も単純な入力値を使う。
- テスト関数に説明的な名前をつけて、何をしているのかを明らかにする。Test1()ではなく、Test_<関数名>_<状況>のような名前にする