Clean Code スキル

このスキルは、Robert C. Martin (Uncle Bob) の「Clean Code」の原則を具現化しています。「動作するコード」を「きれいなコード」に変換するために使用してください。

🧠 中核となる哲学

「コードが他の開発者によって読むことができ、改善できるなら、そのコードはきれいである。」— Grady Booch

使用するタイミング

このスキルを使用する場合：

• 新しいコードを書く場合：最初から高品質を確保するため。
• プルリクエストをレビューする場合：建設的で原則に基づいたフィードバックを提供するため。
• レガシーコードをリファクタリングする場合：コード臭を特定して除去するため。
• チームの基準を改善する場合：業界標準のベストプラクティスに合わせるため。

1. 意味のある名前

• 意図が明確な名前を使用する：d ではなく elapsedTimeInDays。
• 誤った情報を避ける：実際には Map である場合に accountList を使用しない。
• 意味のある区別をする：ProductData vs ProductInfo を避ける。
• 発音しやすく、検索可能な名前を使用する：genymdhms を避ける。
• クラス名：名詞を使用する（Customer、WikiPage）。Manager、Data を避ける。
• メソッド名：動詞を使用する（postPayment、deletePage）。

2. 関数

• 小さく！：関数は思っているより短くするべき。
• 1つのことだけをする：関数は1つのことだけをして、それをよくやるべき。
• 抽象化のレベルを1つに：高レベルのビジネスロジックと低レベルの詳細（正規表現など）を混在させない。
• 説明的な名前：check より isPasswordValid が良い。
• 引数：0個が理想的、1～2個は可、3個以上は非常に強い正当性が必要。
• 副作用がない：関数は隠れてグローバル状態を変更してはいけない。

3. コメント

• 悪いコードにコメントを付けるな—書き直せ：ほとんどのコメントは自分たちをコードで表現できなかったことの証。
• コードで自分たちを説明する：

  # Check if employee is eligible for full benefits
  if employee.flags & HOURLY and employee.age > 65:
  

  対

  if employee.isEligibleForFullBenefits():
  

• 良いコメント：法的コメント、情報提供的（正規表現の意図）、明確化（外部ライブラリ）、TODO。
• 悪いコメント：つぶやき、冗長、誤解を招く、強制、ノイズ、位置マーカー。

4. フォーマット

• 新聞の比喩：上部に高レベルの概念、下部に詳細。
• 垂直密度：関連する行は互いに近くにあるべき。
• 距離：変数は使用箇所の近くで宣言するべき。
• インデント：構造的な可読性に不可欠。

5. オブジェクトとデータ構造

• データ抽象化：実装をインターフェースの背後に隠す。
• デメテルの法則：モジュールは操作するオブジェクトの内部を知るべきではない。a.getB().getC().doSomething() を避ける。
• データ転送オブジェクト（DTO）：public 変数と関数がないクラス。

6. エラーハンドリング

• 戻り値ではなく例外を使用する：ロジックをきれいに保つ。
• Try-Catch-Finally を最初に書く：操作のスコープを定義する。
• Null を返さない：呼び出し側が毎回 null をチェックすることを強制する。
• Null を渡さない：NullPointerException につながる。

7. ユニットテスト

• TDD の3つの法則：
  1. 失敗するユニットテストがあるまで、プロダクションコードを書かない。
  2. 失敗するのに十分なユニットテストを超えて書かない。
  3. 失敗するテストを通すのに十分なプロダクションコードを超えて書かない。
• F.I.R.S.T. の原則：Fast（高速）、Independent（独立）、Repeatable（反復可能）、Self-Validating（自己検証）、Timely（タイムリー）。

8. クラス

• 小さく！：クラスは単一責任を持つべき（SRP）。
• ステップダウンルール：コードはトップダウンの物語のように読めるようにしたい。

9. 臭いと発見的手法

• 硬性：変更しにくい。
• 脆性：多くの場所で破損する。
• 不動性：再利用しにくい。
• 粘性：正しいことをするのが難しい。
• 不要な複雑さ/重複。

🛠️ 実装チェックリスト

• この関数は20行より短いか？
• この関数は正確に1つのことをしているか？
• すべての名前は検索可能で意図が明確か？
• コードをより明確にしてコメントを避けたか？
• 多すぎる引数を渡していないか？
• この変更に対して失敗するテストがあるか？

制限事項

• このスキルは、タスクが上記で説明されたスコープと明らかに一致する場合にのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家の審査の代替として扱わないでください。
• 必要な入力、権限、安全境界、または成功基準が不明な場合は、停止して明確化を求めてください。