Menu
コードの作成、リファクタリング、コードレビューを行う際に使用します。リーダブルコード、DRY、YAGNI、PEP8などのベストプラクティスに基づいて、保守性の高い高品質なコードを書くためのガイドラインを提供します。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Git worktreeを使用する際、.gitignoreされた.envファイル等がworktreeに存在しない問題を解消するスキル。メインworktreeから現在のworktreeへ、.gitignore済みファイル（.env, .env.*, *.local など）を一括コピーする。使用トリガー: (1) /create-worktree-env で呼び出されたとき, (2) worktree内で.envがない・環境変数が読み込めない等の問題が発生したとき, (3) 新しいworktreeを作成した直後に環境ファイルのコピーを依頼されたとき
本プロジェクトにおけるUI/UXデザインの品質向上、およびフロントエンド実装におけるルールを定義します。
Based on SOC occupation classification
| name | clean-code-principles |
| description | コードの作成、リファクタリング、コードレビューを行う際に使用します。リーダブルコード、DRY、YAGNI、PEP8などのベストプラクティスに基づいて、保守性の高い高品質なコードを書くためのガイドラインを提供します。 |
このスキルは、『リーダブル・コード』、DRY原則、YAGNI原則、PEP8、SOLID原則などのソフトウェアエンジニアリングのベストプラクティスを統合し、高品質で保守性の高いコードを書くためのガイドラインを提供します。
すべてのコード作成およびコードレビュータスクにこれらの原則を適用してください。
核心: コードは書かれる回数よりも読まれる回数の方がはるかに多い。書き手ではなく読み手のために最適化する。
意図を明らかにする名前を使う: 名前は、それが存在する理由、何をするのか、どう使うのかを説明すべき
# 悪い例
d = 86400 # 1日の秒数
# 良い例
SECONDS_PER_DAY = 86400
意味のある区別をする: 連番（a1, a2）やノイズワードを避ける
# 悪い例
def get_user_info_data():
# 良い例
def get_user_profile():
発音可能で検索可能な名前を使う
# 悪い例
genymdhms = datetime.now()
# 良い例
generation_timestamp = datetime.now()
小さな関数: 各関数は一つのことをうまく行うべき
関数ごとに一つの抽象レベル: 高レベルの概念と低レベルの詳細を混在させない
説明的な名前: 関数名は動詞または動詞句であるべき
# 良い例
def save_user_to_database(user):
def is_valid_email(email):
def calculate_monthly_payment(principal, rate, term):
引数を最小限にする: 理想はゼロ、許容できるのは1〜2個、3個は正当化が必要
# 悪い例
def create_user(name, email, age, address, phone, role, status):
# 良い例 - データクラスや辞書を使う
def create_user(user_data: UserData):
WHYを説明し、WHATは説明しない: コードは何をするかを自己説明的であるべき
# 悪い例
# iをインクリメント
i += 1
# 良い例
# ヘッダー行をスキップ
i += 1
自明でないビジネスロジックにコメントする
# 金融規制で日次複利計算が義務付けられているため、
# 複利計算式を使用
interest = principal * (1 + rate/365) ** (365 * years)
コメントアウトされたコードは削除: バージョン管理が記憶している
コメントを最新に保つ: 古いコメントはコメントがないよりも悪い
原則: すべての知識は、システム内で単一、明確、信頼できる表現を持つべき
繰り返されるコードを関数やクラスに抽出
# 悪い例
user1_full_name = user1.first_name + " " + user1.last_name
user2_full_name = user2.first_name + " " + user2.last_name
# 良い例
def get_full_name(user):
return f"{user.first_name} {user.last_name}"
繰り返される値には設定ファイルを使う
繰り返されるパターンには抽象化を作る
ただし: 過度なDRYは避ける - コードが似ていても目的が異なる場合、重複は許容される場合がある
原則: 実際に必要になるまで機能を実装しない
早すぎる抽象化を避ける: 具体的に始め、パターンが現れたらリファクタリング
「将来のための」実装をしない: 「念のため」で機能を追加しない
使われていないコードを削除: 呼び出されていなければ削除する
# 悪い例 - 使われない柔軟性を追加
def calculate_price(base_price, discount=None, tax_rate=None,
currency=None, rounding_mode=None):
# base_priceしか使われていない
# 良い例 - 必要になったらパラメータを追加
def calculate_price(base_price):
return base_price * 1.1 # 10%の税
# 命名規則
class UserAccount: # クラスはCapWords
pass
def calculate_total(): # 関数はlowercase_with_underscores
pass
CONSTANT_VALUE = 100 # 定数はUPPERCASE
user_name = "John" # 変数はlowercase_with_underscores
# インデント: 4スペース（タブ禁止）
# 最大行長: 2000文字
# import文: 標準ライブラリ、サードパーティ、ローカル（空行で区切る）
import os
import sys
import requests
from flask import Flask
from myapp.models import User
// 変数と関数はcamelCase
const userName = "John";
function calculateTotal() {}
// クラスはPascalCase
class UserAccount {}
// 定数はUPPER_SNAKE_CASE
const MAX_RETRY_COUNT = 3;
// デフォルトはconst、再代入が必要な場合はlet、varは使わない
コードをレビューまたは書く際に確認すること：
名前付き定数を使う
# 悪い例
if user.age > 18:
# 良い例
LEGAL_ADULT_AGE = 18
if user.age > LEGAL_ADULT_AGE:
やりすぎるクラスや関数
「早すぎる最適化は諸悪の根源」 - Donald Knuth
一つの変更で多くの場所を修正する必要がある（DRY違反）
抽象化せずにコードを複製
深くネストした条件文
# 悪い例
if condition1:
if condition2:
if condition3:
# 深いネスト
# 良い例 - 早期リターン
if not condition1:
return
if not condition2:
return
if not condition3:
return
# メインロジック
このスキルが有効な状態で通常通りコーディングタスクを依頼すると、自動的にこれらの原則が適用されます。
Pythonでユーザー認証システムを実装してください
React でダッシュボードコンポーネントを作成してください
既存のコードの改善点を確認する際にも使用できます。
このコードをレビューして、改善すべき点を教えてください
明示的に原則を指定できます。
このコードをDRY原則に従ってリファクタリングしてください
YAGNI原則を意識して、シンプルな実装にしてください
「コンピュータが理解できるコードは愚か者でも書ける。良いプログラマは人間が理解できるコードを書く。」 - Martin Fowler
「クリーンなコードは、ルールに従うことで書かれるものではない。何をすべきで何をすべきでないかのリストを学ぶことでソフトウェア職人にはなれない。プロフェッショナリズムと職人技は、規律を駆動する価値観から来る。」 - Robert C. Martin
目標は完璧さではなく、継続的な改善です。これらの原則を、状況とトレードオフを考慮して実用的に適用してください。