simplify-code

コードを簡潔にする

動作を変えずに、コードの明瞭さ、一貫性、保守性を高めます。プロジェクト内の規約に従ってください。変更範囲は元のコードより広げず、読みやすく、デバッグしやすく、保守しやすい状態にします。

対象範囲

• ユーザーが選択またはタグ付けしたコードを指定した場合は、そのコードを使用します。
• ユーザーが対象を指定した場合は、指定されたファイル、ディレクトリ、または説明を使用します。
• 対象を指定せず、全般的な簡素化を求められた場合は、まずステージ済みのソースコードの変更を確認します。ステージ済みの変更がなければ、ステージされていないソースコードの変更を確認します。
• 編集は、対象または差分に含まれる言語のソースコードファイルに限定します。リポジトリには複数の言語が含まれる場合があります。対象ファイル、近隣のコード、プロジェクトの構成、ビルド設定から言語を推測し、拡張子の一覧を網羅的なものとして扱わないでください。
• ユーザーが明示的に編集を求めない限り、ドキュメント、JSON、YAML、ロックファイル、画像など、コード以外のファイルは簡素化の対象から除外します。
• 絞り込み後にソースコードファイルが残らない場合は、簡素化するものがないことを報告し、変更を加えないでください。

ワークフロー

1. 対象コードを特定します。

   • 編集前に、関連ファイル、ローカルの規約、近隣の実装パターンを確認します。
   • 外部から観察可能な動作を把握します。入力、出力、副作用、エラー処理、レンダリング結果、アクセシビリティのセマンティクス、永続化、公開 API の形状、シリアライズ、順序、タイミング、ユーザーに表示されるテキストが含まれます。
   • 微妙なロジックを変更する前に、近隣のテストや例を確認します。利用できる場合は、それらを動作の根拠にします。
   • 意図的な複雑さを簡素化する前に、ADR、設計ドキュメント、制約に関するコメントを確認します。この作業では、記録された決定を維持します。
   • 曖昧な点を把握します。妥当な前提に基づいて進めますが、意図を誤って推測すると外部から観察可能な動作が変わる可能性がある場合に限り、作業を止めて質問します。

2. 意味のある簡素化を見つけます。

   • 不要な分岐、ネスト、重複、間接化を減らします。
   • 動作を維持しながら、状態のスコープを狭めます。変更より return、フィールドよりローカル変数、モジュール状態よりフィールドを優先します。同期が必要な値のコピーを保持するのではなく、値を導出します。新しい読者が検索せずに「X はどこから来るのか」「X を変えられるものは何か」に答えられる状態を目指します。
   • 到達不能であることが証明できる分岐や、未使用のシンボル、未使用のパラメーターなど、不要なコードを削除します。実行される可能性のあるガードは動作の一部です。到達不能であると証明できない限り、残してください。
   • 変わるのが小さなペイロードフィールドだけであれば、ほぼ同じ分岐本体をまとめます。
   • ネストした三項演算子は避けます。条件が複数ある場合は、switch または if/else チェーンを使います。
   • 読みやすい場合は、A -> x、B -> y のような簡潔で直接的なマッピングを、単純な二択や列挙型のケースで優先します。
   • 関連するロジックをまとめ、異なる関心事は別の単位に分けます。
   • 簡潔で重複のない実装でも、明瞭さとデバッグのしやすさが保たれる場合は、それを優先します。一方、抽出しても再利用されず、名前を付ける手間が増えるだけなら、小さな単発の判断はその場に残します。
   • 最もシンプルで読みやすい形を選びます。明示的に見せることだけを目的にコードを冗長にしないでください。
   • より適切な名前がプロジェクトで確立された用語を反映する場合は、不明瞭な変数名、関数名、プロパティ名、型名を改善します。
   • 抽象化の追加や削除は、複雑さの軽減、動作の分離、テスト容易性、再利用、ドメイン上の意味といった具体的な利点がある場合に限ります。これらのいずれかをもたらす抽象化は維持します。削除候補には、呼び出し元が 1 つだけのラッパー、2 つ目の実装がないアダプター、未使用の将来機能のために追加された間接化などがあります。その単位を削除したと想像してください。複雑さがなくなるなら、それは単なる受け渡しです。複雑さが呼び出し元の間に再び現れるなら、残してください。
   • 明確な利点なしに認知負荷が増えるリファクタリングは行いません。
   • 明らかな構文や制御フローを説明するコメントは削除します。ただし、意図、トレードオフ、不変条件、または自明でない動作を説明するコメントは残します。
   • コメントアウトされたコードは、明らかに古く、ローカルの慣習として削除が適切な場合に限り削除します。それ以外は残すか、質問します。

3. 動作を維持し、標準に従ってください。

   • 元のすべての機能、出力、副作用、エラー、順序、エッジケースの動作を維持してください。
   • ユーザーが明示的に変更を希望している場合、またはローカルのテストや規約から内部仕様であり安全に更新できると判断できる場合を除き、パブリック API、エクスポート名、型の契約、ワイヤ形式、ストレージキー、分析イベント、エラーテキスト、DOM 構造、ARIA ラベル、スナップショットに影響する出力など、外部から見える契約を維持してください。
   • 言語の規約、モジュールとインポート、型またはインターフェース、コンポーネント、エラー処理、命名に関するプロジェクトの標準に従ってください。
   • 関連する場合は、インポート順序、明示的なパブリック型またはトップレベル型、コンポーネントの props パターン、ファイル拡張子の規約など、フレームワーク固有の標準に従ってください。

4. 見た目だけの変更による差分を避けてください。

   • 改行、折り返し、インデント、関数シグネチャ、引数リスト、複数行の式の形を変えるだけの再フォーマットは行わないでください。
   • フォーマットはフォーマッターに任せてください。
   • 変更前と変更後の読みやすさが同等であれば、変更箇所が少なく、差分の小さい方を選んでください。

5. 結果を検証してください。

   • 変更したコードを読み直し、微妙なエッジケースの違いも含めて、ビジネスロジックと外部から観察できる動作を元のコードと比較してください。
   • 利用可能な範囲で、対象を絞ったテスト、型チェック、リンター、ビルドなど、最も関連性の高いチェックを実行してください。
   • チェックを実行できない場合や、タスクに対して範囲が広すぎる場合は、その不足を明記してください。
   • 差分を確認し、関係のない変更を取り除いてください。

出力

最終的な要約は、変更の規模に応じたものにしてください。小規模なタスクでは、変更点と検証方法を記載した具体的な箇条書き 1〜3 項目、または短い段落にしてください。

大規模な作業では、次の構成にしてください。

• 簡素化: 簡素化ごとに 1 項目を記載し、対象ファイルを明示してください。3 つの呼び出し元からヘルパーを抽出する場合は、1 つの簡素化として扱います。以下のサブ項目を含めてください。
  • 変更前: 以前の構成または複雑さの原因
  • 変更後: 新しい構成
  • 改善点: 読みやすさ、保守性、重複の削減、認知負荷の軽減
• 検証: 実行したコマンドと結果を列挙するか、実行しなかったことを明記してください。
• 対象範囲: 調査したファイルと、変更が不要だったファイルを 1 行で示してください。

要約は具体的にし、理解に影響する重要な変更だけを含めてください。簡素化によって実際に実現され、検証によって裏付けられていない限り、動作が変わった、パフォーマンスが向上した、またはバグが修正されたと主張しないでください。