cleanse について
動作を保ちながらコードの可読性を高めるリファクタリングスキルです。コードレビューや保守向けに、制御フロー、ロジック、命名、関数構成を順に見直します。
主な機能
- 01ネストした制御を早期リターンに変更
- 02冗長なコメントや変数を削除
- 03条件式と状態管理を簡素化
- 04変数名とメソッド名を改善
- 05役割の多い長い関数を分割
活用シーン
- 01コードをすばやく理解しやすくする
- 02複雑で読みにくい関数を整理
- 03将来の保守に必要な理解負荷を軽減
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ andrewgleave/ skills --skill cleanseインストール後、Claude Code で/cleanseを入力して読み込まれたか確認します。
同梱ファイルREADME.md
詳細
対象範囲
ユーザーがファイルまたはディレクトリを指定した場合は、それらを確認してください。指定がない場合は、作業を始める前に、何を確認したいか尋ねてください。
目標
初めて見た人でも、このコードをすぐに理解できるようにしてください。半年後にこのファイルを開いた人が、数秒でその役割を理解できることを目指します。 すべての変更で、元の機能と動作を維持してください。
確認する内容
対象コードを注意深く読み、次の手順を順番に適用してください。変更は直接加えてください。提案を列挙するだけにしないでください。
1. 制御フローを平坦化する
ネストした条件分岐は、読みやすさを最も損なう要因です。平坦化してください。
- if/else チェーンを早期リターンとガード節に変換します。最初に終了条件を置き、その後に通常の処理を記述します。
- 関数の主要な処理が条件分岐内にひとつだけある場合は、条件を反転して早期リターンします。
- else ブロックが return または continue だけの場合は、else を削除します。早期リターンで処理できています。
2. ノイズを取り除く
コードの理解に役立たないものは削除してください。
- コードの内容を言い換えただけのコメント —
counter += 1の上にある// increment counterはノイズです。削除してください。 - 冗長な型注釈 — 右辺から型が明らかで、言語が型推論をサポートしている場合は、型注釈を削除してください。
- 不要な中間変数 — 変数が次の行で一度だけ使われている場合は、インライン化してください(名前によって明確さが増す場合を除きます)。
理由を説明するコメントだけを残してください。回避策、制約、わかりにくいビジネスルールなどは重要です。それ以外はすべて削除してください。
3. ロジックを単純化する
- 言語がサポートしている場合は、簡単な if/else を単一の式にまとめます(三項演算子、nil 合体演算子、パターンマッチングなど)。
- ループ内の状態を追跡するブール値フラグを、早期終了または関数型変換(map、filter、first)に置き換えます。
- 一度しか使わず、インラインで読める短いヘルパーはインライン化します。一度限りの処理をヘルパーとして抽出しないでください。抽象化を急ぐより、似た処理が3行並んでいるほうが適切です。
4. 名前を改善する
- 意味が曖昧な変数名を変更します。
data、result、temp、info、val、objは、何を表すのかがわかりません。内容を具体的に示す名前を使ってください。 - ただし、スコープが狭い一時変数(ループインデックスや短いクロージャなど)は短い名前のままにし、ひとことで十分な場合も簡潔にします。3行のループなら
iで問題ありません。 - 言語の命名規則に従ってください。JS/Swift では camelCase、Python/Rust では snake_case などです。
- メソッド名だけで、その処理内容がわかるようにしてください。メソッドの役割を説明するコメントが必要なら、メソッド名を変更してください。
5. 宣言を使用箇所の近くに移動する
関数の先頭で定義した変数を40行目まで使わないと、読者はその間ずっと変数を意識し続けなければなりません。最初に使う直前に宣言を移動してください。後から処理を抽出しやすくなります。
6. 長い関数を分割する
関数が複数の異なる処理を順番に行っている場合は、分割してください。それぞれの処理が単独で読みやすくなるようにします。抽出した各関数にも、上記の手順を適用してください。多くのパラメーターを受け渡す必要がある場合や、ロジックが深く絡み合っている場合は、無理に分割せず、読みやすさの懸念として指摘してください。
変更の適用方法
- 対象ファイルを十分に読みます。
- すべての変更を直接加えます。効率よく進め、関連する編集はまとめて行ってください。
- 編集後、可能であればコードが引き続きコンパイルまたは解析できることを確認します(プロジェクトに lint またはビルドコマンドがある場合は実行してください)。
- 変更点を簡潔に列挙します。詳細は diff で確認できます。
してはいけないこと
- 以前になかったコメント、docstring、型注釈を追加しないでください(名前の変更によって曖昧になる場合を除きます)。
- アーキテクチャをリファクタリングしたり、モジュール間でファイルを移動したりしないでください。これは明確さを高める作業であり、再設計ではありません。
- 名前が明らかに誤解を招く場合を除き、公開 API のシグネチャを変更しないでください。
- 奇抜な工夫は避けてください。目標は、自己説明的で、初見でも読めるほど平易で明快なコードです。