ブログ記事
「わかりやすさ」を技術として扱う：Boswell & Foucher『リーダブルコード』
コードは書かれる時間よりも読まれる時間の方が長い。Dustin Boswell と Trevor Foucher の『リーダブルコード』は、この事実を出発点として、「他の人が理解しやすいコードを書く」ための具体的な技法を整理した入門書だ。
1. 「理解しやすいコード」の定義
本書の定義はシンプルだ。「コードは、他の人が最短時間で理解できるように書かなければならない」。
ここで重要なのは「最短時間」という基準だ。コードが短ければ読みやすいとは限らない。変数名をすべて1文字にすれば行数は減るが、理解にかかる時間は増える。行数を最小化することが目的ではなく、理解のコストを最小化することが目的だ。
また「他の人」には、3ヶ月後の自分自身も含まれる。書いた瞬間は文脈が頭にあるため何でも読めるが、時間が経つと文脈が消える。
2. 名前に情報を詰め込む
本書の前半は名前付けに多くのページを割いている。
変数名・関数名・クラス名には、意味のある情報を詰め込む。tmp や data のような汎用的な名前は、何を指すかを読み手に伝えない。secondsElapsed や rawHtmlData のように、型・単位・状態を名前に含めることで、コードの文脈を読まずに済む。
「暗黙の単位」の問題は特に危険だ。delay が秒なのかミリ秒なのかを名前だけでは判断できないと、呼び出し側が間違った前提を持ってしまう。delayMs や timeoutSec のように明示することで、誤解が防げる。
3. コメントすべきことと、すべきでないこと
本書が明確にしているのは「コメントでコードを翻訳しない」という原則だ。
コードを見れば分かることをコメントに書くのは冗長で、コードとコメントの二重管理が必要になる。コメントが必要なのは、コードに表れない「なぜ」——意図、警告、歴史的経緯、非自明な副作用——を伝えるときだ。
一方、「TODO」「FIXME」「HACK」のような注記は積極的に書くべきとされている。問題の存在を明示することで、将来の読み手が意図的な選択と偶発的な問題を区別できる。
4. 複雑な条件を単純化する
本書の後半はロジックの整理に焦点を当てている。
ネストが深い条件分岐は、早期リターン（ガード節）で平坦化できる。「例外条件を先に処理してリターンし、メインのロジックを前に出す」という構造は、読み手が追わなければならない状態を減らす。
三項演算子や複雑な論理式も、読み手を驚かせることがある。短く書けることと、理解しやすいことは異なる。本書が繰り返すテーマは「賢いコードより、驚きのないコードを書く」という姿勢だ。
DevBookPath のマップで確認する
この本の前後の読書順は、DevBookPath のグラフで確認できます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有