ブログ記事
「わかりやすさ」を技術として扱う：Boswell & Foucher『リーダブルコード』
コードは書かれる時間よりも読まれる時間の方が長い。Dustin Boswell と Trevor Foucher の『リーダブルコード』は、この事実を出発点として、「他の人が理解しやすいコードを書く」ための具体的な技法を整理した入門書だ。
1. 「理解しやすいコード」の定義
本書の定義はシンプルだ。「コードは、他の人が最短時間で理解できるように書かなければならない」。
ここで重要なのは「最短時間」という基準だ。コードが短ければ読みやすいとは限らない。変数名をすべて1文字にすれば行数は減るが、理解にかかる時間は増える。行数を最小化することが目的ではなく、理解のコストを最小化することが目的だ。
また「他の人」には、3ヶ月後の自分自身も含まれる。書いた瞬間は文脈が頭にあるため何でも読めるが、時間が経つと文脈が消える。
2. 名前に情報を詰め込む
本書の前半は名前付けに多くのページを割いている。
変数名・関数名・クラス名には、意味のある情報を詰め込む。tmp や data のような汎用的な名前は、何を指すかを読み手に伝えない。secondsElapsed や rawHtmlData のように、型・単位・状態を名前に含めることで、コードの文脈を読まずに済む。
「暗黙の単位」の問題は特に危険だ。delay が秒なのかミリ秒なのかを名前だけでは判断できないと、呼び出し側が間違った前提を持ってしまう。delayMs や timeoutSec のように明示することで、誤解が防げる。
flowchart LR
subgraph NG["❌ 情報のない名前"]
N1["d（何の変数？）"]
N2["tmp（何を保存？）"]
N3["delay（秒？ミリ秒？）"]
end
subgraph OK["✅ 情報が詰まった名前"]
O1["daysElapsed（経過日数）"]
O2["cachedUserData（何をキャッシュ？）"]
O3["delayMs（ミリ秒単位の遅延）"]
end
style NG fill:#fce8e8,stroke:#e53935
style OK fill:#e8f8e8,stroke:#4caf50
3. コメントすべきことと、すべきでないこと
本書が明確にしているのは「コメントでコードを翻訳しない」という原則だ。
コードを見れば分かることをコメントに書くのは冗長で、コードとコメントの二重管理が必要になる。コメントが必要なのは、コードに表れない「なぜ」——意図、警告、歴史的経緯、非自明な副作用——を伝えるときだ。
一方、「TODO」「FIXME」「HACK」のような注記は積極的に書くべきとされている。問題の存在を明示することで、将来の読み手が意図的な選択と偶発的な問題を区別できる。
4. 複雑な条件を単純化する
本書の後半はロジックの整理に焦点を当てている。
ネストが深い条件分岐は、早期リターン（ガード節）で平坦化できる。「例外条件を先に処理してリターンし、メインのロジックを前に出す」という構造は、読み手が追わなければならない状態を減らす。
三項演算子や複雑な論理式も、読み手を驚かせることがある。短く書けることと、理解しやすいことは異なる。本書が繰り返すテーマは「賢いコードより、驚きのないコードを書く」という姿勢だ。
5. この本が解決できる具体的な状況
「コードレビューで『わかりにくい』と言われるが、何を直せばいいのかわからない」——この状況は、可読性を改善する技法の語彙を持っていないことが原因であることが多い。本書はその語彙を与える。
チームで変数名・関数名を巡って意見が割れたとき、「なぜその名前がより良いか」を説明できるかどうかは、チームの設計レベルを左右する。本書はこの議論の共通言語になる。
6. 向いている人・向いていない人
向いている人：
- コードレビューで「わかりにくい」と指摘される機会が多い、または指摘する言葉を持てていない
- 数年後に自分が書いたコードを見て「なぜこう書いたのか」理解できないことが続いている
- チームへのコードスタイルの共通認識を作りたいエンジニア・テックリード
向いていない人：
- アーキテクチャ設計や SOLID 原則など、コード全体の構造を学びたい人（本書は命名・コメント・ロジック整理が中心で設計論ではない）
- 上級者（本書は中級者以降には自明に感じられる内容が多い）
7. 読み終えた後のステップ
命名や構造の整理ができるようになると、次に進む方向は関心のありかで3つに分かれる。
クラス設計や責務の分割という「そもそもどう設計すべきだったか」に進みたいなら、『Clean Code』が個々のテクニックを職業倫理と設計原則の体系へ束ねてくれる。日々の判断を貫く職業哲学——DRYや直交性、変化への構え——まで視野を広げたいなら、『達人プログラマー』が個々の技法を「なぜそうするか」という態度へつなげる。そして、今書いているコードではなく既存のコードを読みやすい形に寄せていく手順が要るなら、リファクタリングが「コードの臭い」を手がかりに振る舞いを変えず小さく構造を改善する段取りを与える。
「読みやすいコード」の語彙を持てた今が、次の一冊を選ぶタイミングだ。今困っているのが設計の原則か、判断の姿勢か、既存コードの改善手順かで選ぶとよい。
筆者の体験から
前職の受託開発でtoBの業務システムの改修をしていた頃、コードレビューで変数名や条件分岐について同じ指摘を繰り返し受けていた。「読みにくいから」としか理由がもらえず、何を直せばいいのか分からないまま、先輩に勧められて買った。
ある画面にはflagという変数がいくつも出てきて、trueが「保存済み」なのか「編集中」なのかコードを読まないと分からず、「このflag、何のflagですか」と別のPRで3回ほど同じ指摘を受けたことがある。暗黙の状態を名前に出すという本書の話を読んで納得できた。isDataChangedのように状態が伝わる名前へ置き換えたところ、以後は同種の指摘を受けなくなった。
引っかかったのは、当時「これさえ守れば良いコードが書ける」と期待しすぎていた点だ。クラス設計や責務分割といったもっと大きい単位の悩みは別に残ったし、業務ルールが後から継ぎ足された複雑な条件分岐は、早期リターンだけでは片付かなかった。
DevBookPath のマップで確認する
この本の前後の読書順は、DevBookPath のグラフで確認できます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有