リーダブルコード

第2章 名前に情報を詰め込む

tmp や retval は、その変数について何も語っていない。名前は一番短いコメントだと思えば、情報を詰める価値がある。ただし長ければいいわけではなく、読む人が何を知りたいかで決まる。

第3章 誤解されない名前

filter という名前は「残す」のか「除く」のか分からない。名前の良し悪しは、誤読される余地があるかどうかで測る。自分が分かるかではなく、他人が別の意味に取れるか。

第7章 制御フローを読みやすくする

条件式は、変化する側を左に、比較対象を右に置くと読みやすい。ネストは早期リターンで潰す。読む人の頭の中のスタックを浅く保つ、という考え方が腑に落ちた。

第8章 巨大な式を分割する

長い式は、途中に名前をつけた変数を置くだけで別物のように読める。パフォーマンスを気にして1行に詰める癖があったが、読めないコードの方がよほど高くつく。

第9章 変数と読みやすさ

変数のスコープが広いほど、読み手は長く覚えていなければならない。使う場所の近くで宣言する。書く側の都合ではなく、読む側の記憶容量の話だと考えると納得できる。

第9章 説明変数

条件式そのものに名前をつけると、コメントなしで意図が見える。年齢を直接比較するより、その条件が何を意味するかを変数名にした方が、なぜその境界なのかが残る。

第5章 コメントすべきこと

コードを読めば分かることはコメントに書かない。書くべきは、なぜそうしたか、なぜ別の方法を選ばなかったか。この本を読んでから、コメントの量は減って質は上がった。

第14章 テストと読みやすさ

テストコードも読まれる。何を確かめているかが1行目で分かるべきで、セットアップが長いテストは、対象の設計が複雑すぎるサイン。テストは設計へのフィードバックでもある。