クリーンコード

クリーンコードとは、書いた本人以外の人間が読んで意図を理解できるコードのことだ。Robert C. Martinが2008年に著した『Clean Code』はこの概念を広めた書籍であり、命名・関数・コメント・フォーマットにわたる実践的なガイドラインを提供している。コードは一度書かれた後、何度も読まれる。読まれる回数に対して書く回数は圧倒的に少ないため、書く手間よりも読む手間を最小化することに投資すべきだという考え方がその根底にある。

意図を伝える命名は最も費用対効果が高い品質改善だ。変数名がdやtmpであれば読者はその意味を文脈から推測しなければならない。elapsedTimeInDaysと書けば、それだけで意味が自明になる。関数名は動詞で始め、副作用のある操作と副作用のない照会を名前で区別できることが望ましい。クラス名は名詞で、責務を一言で表現できるものが理想だ。

関数は小さく・単一の責任を持つべきとされる。マジックナンバーは名前付き定数に置き換え、コメントは「何をしているか」ではなく「なぜそうしているか」を書く。良いコードは自己説明的であるべきであり、コメントでコードの稚拙さを補う行為は避けるべきだ。Guard Clause（早期リターン）を使えばネストを減らし、正常系の流れを主軸に読めるようになる。

コードレビューで着目するポイント

変数・関数・クラスの名前が意図を過不足なく表現しているか
関数が「一つのことだけ」をしているか（抽象レベルが一段階になっているか）
マジックナンバーや意味不明な文字列リテラルが直書きされていないか
コメントが「何をしているか」の説明に留まっていないか（コードで表現できないか）
ネストが深すぎないか（Early Returnやガード節で平坦にできないか）
長い引数リストや真偽値フラグを関数に渡していないか
関数の抽象レベルが混在していないか（高レベル処理の中に低レベル実装詳細が混入）

典型的なアンチパターン

フラグ引数（Flag Arguments）: processUser(user, true) のように真偽値を引数で渡す。trueがどんな意味かを関数定義まで追わないと理解できず、2つの責務が1関数に入っているサインでもある。

コメントアウトされたコード: 削除すべきコードがコメントで残り続ける。バージョン管理システムがあれば履歴から取り出せるため、コードベース内に残す理由はない。読者の注意を奪う。

誤解を招く名前: getUserData() が副作用としてキャッシュ更新や外部APIコールを行う。名前の表す動作と実際の動作の乖離は、デバッグを著しく困難にする。

参考リソース

Robert C. Martin『Clean Code: A Handbook of Agile Software Craftsmanship』（Prentice Hall、2008）
Martin Fowler『Refactoring: Improving the Design of Existing Code』第2版（Addison-Wesley、2018）
Sandi Metz「Rules for OO Programming」— メソッドは5行以内など実践的なルール
Google Java Style Guide — 命名と構造に関する具体的な指針
SonarQube — 静的解析ツールとしてクリーンコードのルールを自動検出