いつかは読むべきだなーと思っていた『リーダブルコード』、ようやく読んだので内容をまとめておきます。
第I部 表面上の改善
名前
変数やメソッド、クラスの名前は明確で具体的、かつ誤解のないようにすべき。
メソッドの戻り値となる変数の名前を安易にresultやretvalなどにしがちだが、その変数に入る値の具体的な内容を表す変数名のほうが良い。そうしないと、途中で間違った値を代入していても気づきにくいからである。
別の人が読んだ時に違う解釈の余地がある名前は誤解を生む恐れがある。私がちょうど先日「描画されたグラフを消す」メソッドの名前にclearとresetのどちらがいいかと相談されたのだが、resetの場合、例えば「色などの設定を元に戻す」メソッドだという解釈もできそうだと感じclearを勧めた。こちらのほうが明確で誤解を招きにくそうだ。
コメント
コメントすべきこと：その実装を選択した理由、定数の値を決めた背景、将来的に直すべきTODO
コメントすべきでないこと：見ればわかる（コメントがなくても理解にかかる時間が変わらない）こと、わかりにくい（改善の余地がある）コードの補足
「優れたコード＞ひどいコード＋優れたコメント」である。
第II部 ループとロジックの単純化
制御フロー
ifとelseの並びは、肯定の単純な目立つ条件を先に持ってくるべき
個人的には「単純な」が重要だと感じている。以下のようなコードを見るとき、elseにたどり着いた頃には条件が何だったか覚えていられないからだ。
if (条件) {
50行にわたる
とてもとても
長い処理
} else {
3行の処理
}
ネストを浅くする
そのために関数内のreturnや、for文やwhile文のcontinueを活用する。
実際にfor文の中に長いif文があり、ネストが深いコードに何度か出会ったことがあるが、かなり読みづらかった。
変数
一度しか使われない値でも、変数に代入することで変数名がコメントの役割を果たす（説明変数）。一方で説明変数を使わなくても十分明確な場合、必要以上に変数を使うことはコードを複雑にすることになる。
第III部 コードの再構成
"無関係の下位問題"の抽出
ある関数の中で、「その関数の目的」に直接は関わらない処理の塊を別関数に切り出す。これは以下のメリットがある
- 関数の可読性が上がる
- 抽出した関数を再利用できる
- 抽出した関数の改善がしやすくなる
一度に1つのことを
1つのコードで行うタスクを箇条書きにしてみて、その項目を1つずつ解決するようなコードを書く。1つ目と2つ目の項目を並行で処理しようとすると複雑になってしまう。
短いコードを書く
不要なコードを削除する、標準ライブラリを活用するなどして、プロジェクト全体のコード量を小さくする。コード量と保守や機能追加の労力は比例する。
まとめ
第1章にある「コードは他の人が最短時間で理解できるように書かなければいけない」という一文が、この本の内容を最もよく表した言葉でしょう。これを達成するためのテクニックが1冊かけて説明されているわけです。
コーディングを行う際には「このコードは他の人が最短時間で理解できるか？」を常に問う必要があるでしょう。