mcpField
P
python-clean-code

python-clean-code

github.com/ertugrul-dmr開発208163 回インストール27 週間前に更新
リポジトリ

python-clean-code について

python-clean-codeは、Robert C. MartinのClean Code原則をPython向けに適用したコードレビュー・編集スキルです。開発者がルール番号で問題を特定し、コード変更時に修正内容を報告できます。

主な機能

  1. 01コメント、関数、命名、テスト、設計の指針
  2. 02インポート、列挙型、型ヒントのPython固有ルール
  3. 03ルール番号による違反箇所の提示
  4. 04該当ルール番号を添えた修正報告

活用シーン

  1. 01PythonコードのClean Code違反のレビュー
  2. 02引数過多や責務混在の関数のリファクタリング
  3. 03テスト、命名、境界条件の確認

インストール

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

$npx skills add https://github.com/ertugrul-dmr/clean-code-skills --skill python-clean-code

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

詳細

Clean Python：完全リファレンス

Robert C. Martin の第 17 章にある Clean Code の原則をすべて、Python 向けに適用して徹底します。

コメント（C1-C5）

  • C1：コメントにメタデータを書かない（Git を使う）
  • C2：古くなったコメントはすぐに削除する
  • C3：冗長なコメントを書かない
  • C4：コメントが必要なら、適切に書く
  • C5：コメントアウトしたコードは絶対にコミットしない

環境（E1-E2）

  • E1：ビルドコマンドは 1 つにする（pip install -e ".[dev]"）
  • E2：テストコマンドは 1 つにする（pytest）

関数（F1-F4）

  • F1：引数は最大 3 つにする（それ以上は dataclass を使う）
  • F2：出力引数を使わない（戻り値を返す）
  • F3：フラグ引数を使わない（関数を分割する）
  • F4：使われていない関数は削除する

全般（G1-G36）

  • G1：1 ファイルにつき 1 つの言語を使う
  • G2：期待される動作を実装する
  • G3：境界条件を処理する
  • G4：安全策を無効にしない
  • G5：DRY — 重複をなくす
  • G6：抽象化レベルを統一する
  • G7：基底クラスが子クラスを把握しないようにする
  • G8：公開インターフェースを最小限にする
  • G9：使われていないコードを削除する
  • G10：変数は使用箇所の近くに置く
  • G11：一貫性を保つ
  • G12：余計なものを取り除く
  • G13：人為的な結合を避ける
  • G14：フィーチャー・エンヴィーを避ける
  • G15：セレクター引数を使わない
  • G16：意図を曖昧にしない
  • G17：期待される場所にコードを配置する
  • G18：インスタンスメソッドを優先する
  • G19：説明的な変数を使う
  • G20：関数名で処理内容を示す
  • G21：アルゴリズムを理解する
  • G22：依存関係を明示する
  • G23：if/else よりポリモーフィズムを優先する
  • G24：規約に従う（PEP 8）
  • G25：マジックナンバーではなく名前付き定数を使う
  • G26：正確を期す
  • G27：規約より構造を重視する
  • G28：条件判定をカプセル化する
  • G29：否定条件を避ける
  • G30：関数は 1 つのことだけを行う
  • G31：時間的な結合を明示する
  • G32：恣意的な設計をしない
  • G33：境界条件をカプセル化する
  • G34：関数内の抽象化レベルを統一する
  • G35：設定は高いレベルに置く
  • G36：デメテルの法則（連鎖呼び出しを避ける）

Python 固有のルール（P1-P3）

Java 固有のルール（J1-J3）を Python の規約に合わせたものです。

  • P1：ワイルドカードインポート（from x import *）を使わない — PEP 8 に基づく Java とは逆の方針
  • P2：マジック定数ではなく Enum を使う — J3 と同じ原則
  • P3：公開インターフェースに型ヒントを付ける — Python における Java の静的型付けに相当

名前（N1-N7）

  • N1：説明的な名前を選ぶ
  • N2：適切な抽象化レベルの名前を付ける
  • N3：標準的な命名法を使う
  • N4：曖昧さのない名前を付ける
  • N5：スコープに応じた長さの名前を付ける
  • N6：エンコーディングを使わない
  • N7：副作用がわかる名前を付ける

テスト（T1-T9）

  • T1：壊れる可能性のあるものをすべてテストする
  • T2：カバレッジツールを使う
  • T3：些細なテストも省略しない
  • T4：テストを無視する場合は、曖昧さがないか検討する
  • T5：境界条件をテストする
  • T6：バグの近辺を徹底的にテストする
  • T7：失敗にパターンがないか確認する
  • T8：デバッグ時にカバレッジを確認する
  • T9：テストは高速にする（各テスト 100ms 未満）

クイックリファレンステーブル

カテゴリールール要約
コメントC1メタデータを書かない（Git を使う）
C3冗長なコメントを書かない
C5コメントアウトしたコードを残さない
関数F1引数は最大 3 つ
F3フラグ引数を使わない
F4使われていない関数を削除する
全般G5DRY — 重複をなくす
G9使われていないコードを削除する
G16意図を曖昧にしない
G23if/else よりポリモーフィズム
G25マジックナンバーではなく名前付き定数
G30関数は 1 つのことだけを行う
G36デメテルの法則（ドットは 1 つ）
名前N1説明的な名前
N5スコープに応じた長さの名前
テストT5境界条件をテストする
T9テストは高速にする

アンチパターン（やらない → やる）

❌ やらない✅ やる
すべての行にコメントを付ける明らかなコメントを削除する
1 行の処理のためにヘルパーを作るコードをインライン化する
from x import *明示的にインポートする
マジックナンバー 86400SECONDS_PER_DAY = 86400
process(data, True)process_verbose(data)
深いネストガード節、早期リターン
obj.a.b.c.valueobj.get_value()
100 行を超える関数責務ごとに分割する

AI の動作

コードをレビューするときは、ルール番号を挙げて違反を指摘してください（例：「G5 違反：ロジックの重複」）。 コードを修正または編集するときは、修正内容を報告してください（例：「修正済み：マジックナンバーを SECONDS_PER_DAY に切り出しました（G25）」）。

コメント

Markdown 対応