mcpField
C
clean-code

clean-code

github.com/jackjin1997開発1357 回インストール19 週間前に更新
リポジトリ

clean-code について

命名、関数、コメント、書式、エラー処理、クラス、テストにClean Codeの原則を適用するコーディングスキルです。既存コードの可読性と保守性を高めたい開発者向けです。

主な機能

  1. 01意図が伝わる名前の選択
  2. 02小さく役割を絞った関数
  3. 03コードの明瞭さと書式の改善
  4. 04エラー処理の原則の適用
  5. 05TDDとFIRSTのテスト原則

活用シーン

  1. 01名前と関数の責務の見直し
  2. 02不明瞭または重複したコードのリファクタリング
  3. 03変更内容のテスト原則に沿った確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jackjin1997/clawforge --skill clean-code

インストール後、Claude Code で/clean-codeを入力して読み込まれたか確認します。

詳細

クリーンコードスキル

このスキルは、Robert C. Martin（Uncle Bob）による「Clean Code」の原則を体現しています。「動くコード」を「クリーンなコード」に変えるために活用してください。

🧠 基本理念

「コードがクリーンであるとは、元の作者以外の開発者にも読みやすく、拡張しやすいことです。」 — Grady Booch

1. 意味のある名前

  • 意図が伝わる名前を使う：d ではなく elapsedTimeInDays を使います。
  • 誤解を招く名前を避ける：実際には Map であるものに accountList を使わないでください。
  • 意味の違いを明確にする：ProductData と ProductInfo のような名前は避けます。
  • 発音しやすく、検索しやすい名前を使う：genymdhms のような名前は避けます。
  • クラス名：名詞（Customer、WikiPage）を使います。Manager や Data は避けます。
  • メソッド名：動詞（postPayment、deletePage）を使います。

2. 関数

  • 小さく！：関数は、思っているより短くするべきです。
  • 一つのことだけを行う：関数は一つのことだけを、適切に行うべきです。
  • 抽象化のレベルをそろえる：高レベルのビジネスロジックと、正規表現のような低レベルの詳細を混在させないでください。
  • 説明的な名前：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）：パブリック変数を持ち、関数を持たないクラスです。

6. エラー処理

  • 戻り値コードではなく例外を使う：ロジックをすっきり保てます。
  • 最初に try-catch-finally を書く：操作のスコープを定義できます。
  • null を返さない：呼び出し側が毎回 null を確認しなければならなくなります。
  • null を渡さない：NullPointerException の原因になります。

7. ユニットテスト

  • TDD の三原則：
    1. 失敗するユニットテストを書くまでは、本番コードを書かない。
    2. 失敗させるのに必要な範囲を超えて、ユニットテストを書かない。
    3. 失敗するテストを通すのに必要な範囲を超えて、本番コードを書かない。
  • F.I.R.S.T. の原則：高速（Fast）、独立（Independent）、再現可能（Repeatable）、自己検証可能（Self-Validating）、タイムリー（Timely）。

8. クラス

  • 小さく！：クラスは単一責任（SRP）を持つべきです。
  • 段階的に読み進めるルール：コードがトップダウンの説明として読めるようにします。

9. コードの臭いとヒューリスティクス

  • 硬直性：変更が難しい。
  • 脆弱性：さまざまな箇所で壊れる。
  • 移動性の低さ：再利用が難しい。
  • 粘着性：適切な方法を選ぶのが難しい。
  • 不必要な複雑さ／繰り返し。

🛠️ 実装チェックリスト

  • この関数は20行未満ですか？
  • この関数は正確に一つのことだけを行いますか？
  • すべての名前は検索しやすく、意図が伝わりますか？
  • コードをより明確にして、コメントを避けられていますか？
  • 引数を渡しすぎていませんか？
  • この変更に対する失敗するテストがありますか？

コメント

Markdown 対応