Dustin Boswell and Trevor Foucher『リーダブルコード』

概要
ざっくりとしたまとめ
具体的には
感想

概要

知り合いが貸してくれたんで読んだ。プログラミングのコードをどうやって読みやすく書くかっていう話。技術書ではなくて知識もいらないし、几帳面な緑さんの肌に合う話題なんでサクッと読めた。サクッとまとめる。

ざっくりとしたまとめ

コードは人が最短時間で理解できるよう書け。理解とは、変更を加えたりバグを見つけられるという意味。

具体的には

変数とか関数の名前

カラフルな単語を探す。明確で具体的という意味。
- get とか size よりふさわしい単語があるかもしれない。通常そのふたつには軽量なメソッドが期待されている。へーそうなんだ。
- filter では選ぶのか除くのかわからないから select や exclude にすること。へいへい何か言われてますぜ Django の旦那。
- PHPの explode はカラフルだけど split との違いがわからん。そういうやりすぎはいかん。
- 範囲の場合、start と last(それを含む場合) あるいは end(含まない場合) を使う。
変数に重要な属性をつける。
- 単位とか、チェック状況とか、フォーマットによる情報とか。start_ms, size_mb, untrustedUrl, plaintext_password など。
- 全部じゃなくて、意味を間違えたらバグになりそうなところに使うこと。そういう視点でコードを見るのが大事なんだね。
名前の長さはスコープの大きさで決める。
- 名前の長さはスコープの大きさに比例する。
- だがまあ基本的にスコープは短くすること。生きている変数を減らし、邪魔な変数は消す。
bool には否定形の名前を使わない。
- if の式に否定を入れないために、ひとつの if の中身を空っぽにするのはアリ。これはやってなかったなー。
機能を追加した自分にとっては適切な名前でも、他の人が見たらどうかを考えること。
- デバッグ情報を印字する --run_locally というオプションがあった。だけど具体性に欠けるという問題があり --extra_logging --use_local_database というふたつのオプションに分離された。オプションは増えるけど理解しやすい。

美しさ

# まあつまりはこういうこと。
[  1,   2,   3,   4]
[100, 200, 300, 400]

# コードをこんな感じで段落にまとめるのもいい。
# こういうのは好きでよくやってるけど、段落っていうんだこれ。
# ...する処理。
foo()
bar()

# ...する処理。
baz()

# プロジェクトの規約にしたがって一貫性をもたせるのが大切。たとえ間違ったスタイルを使っていたとしても。

コメントはひどい名前の埋め合わせに使うものではない。優れたコード > ひどいコード+優れたコメント である。
コメントには「監督のコメンタリー」を書く。自分の考えとか、コードが汚い理由とか。
よく使われるコメントのフォーマット。
- TODO: あとで手を付ける
- FIXME: 既知の不具合がある
- HACK: あまりキレイに書けてない
- XXX: 大きな問題がある
初めてそのコードを見る人が隣に座っているとして、そいつに口頭で説明することをコメントに書く。
- これはいい視点、いいハックだよね。これを実践したら、理論上、完璧なコードになるのでは?
Python にはキーワード引数があるからいいんだけど、C++ や Java ではインラインコメントで引数を説明するといい。
- Connect(/* timeout_ms= */ 10, /* use_encryption= */ false); こんな感じ。

制御フロー

関数内にひとつしか return を書いてはいけないと思っている人がいるがそれはアホくさい。
悪名高き goto は使わないこと。
ネストを浅くすること。ネストを削除するには、失敗ケースをできるだけ早く関数から返すといい。

式の分割

一度しか使わない変数だとしても、読みやすさのために「説明変数」を書くのはアリ。
or とか and の式が複雑になっちゃったら、ド・モルガンの法則を使って逆にしてみる。

コードを分離するタイミング

分割するのは、そのコードが解決しようとしている高レベルの目標とは無関係の、下位問題を解決しているコード。
- そもそもエンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。
プログラムの多くのコードは、その他のコードを支援するためだけに存在する。たとえば関数の事前処理事後処理などがそれにあたり、そういうのを分離すること。
分離はやりすぎないこと。
- 新しい関数を追加すると、ごくわずかに、しかし確実に読みづらさのコストが発生する。そのコストが相殺されるときだけ追加していい。

コードを小さく軽量に維持する

「その機能の実装に悩まないで、きっと必要ないから。」
- 最終的には不要になる機能を四苦八苦してみろりHPへ実装しようとしていたぼくには、とても耳が痛いコメントだ。
プロジェクトが進んでいくとファイルが増えていく。最終的にはいろんなディレクトリにファイルが散らばり、バグを見つけるのもだんだん面倒になっていく。コードを扱うのが厄介になって楽しくなくなる。新しい機能を追加するのが苦痛になる。
- ならどうすればよいか、コードを小さく軽量に維持するしかない。
書いたものをもったいながってないでがんがん削除していけ。
- これはあらゆるクリエイティブな分野で有効なハックだと思う。