simplify

現在のブランチ、またはユーザーが指定した範囲の変更をレビューしてください。動作を変えずに、以下の基準を適用してください。指定された範囲内のコードだけを変更し、変更後に関連する既存のチェックを実行してください。

コードとコメントで使う言葉

変数名、関数名、コメントはすべて文章です。それぞれに、Orwell のルール（「Politics and the English Language」）を適用してください。

短い言葉で済むなら、長い言葉を使わない。

削れる言葉があれば、必ず削る。

能動態にできるなら、受動態を使わない。

日常的な英語に言い換えられるなら、外国語の表現、学術用語、専門用語を使わない。

ラテン語由来の語彙（reconcile、coalesce、normalize、reconciliation）は技術的で抽象的に聞こえます。アングロサクソン語由来の語彙（prune、run、watch、stop、drop、walk）は短く、具体的です。アングロサクソン語由来の言葉を優先してください。

名前

1. 1 つの概念には 1 つの言葉を使う。 用語を統一してください。sync が「リモートの変更を取り込む」ことを表すなら、「編集内容をディスクに書き込む」ことには使えません。どちらかの名前を変えてください。
2. 文脈から明らかな言葉を削る。 workspaceWatcher というモジュールの中で startNativeWorkspaceWatcher とする必要はありません。watchWorkspace で同じ意味が伝わります。
3. 複合名はたいてい曖昧さの表れです。

• ❌ lastObservedDiskContent は、説明を必要とする名前です。
• ✅ baseline なら読みやすく説明できます。

コメント

コードからは分からない制約、つまり一見して分からない処理がある理由を、平易な英語で説明してください。

• ✅ コードが複雑で実装の意図が分かりにくい場合は、コメントを追加してください。
• ✅ 関数が複雑な処理や副作用を含む場合は、ドキュメントコメントを追加してください。
• 🗑️ 会話の経緯を説明するコメントは削除してください。
• 🗑️ 一目で分かるコードの動作を言い換えただけのコメントは削除してください。

コードの構成

1. 重要な情報を先に示す。 ファイル内では、エクスポートされた関数や重要な関数を先に置き、ヘルパー関数は後に置いてください。要点を埋もれさせないでください。
2. 巨大なまとまりより、関連する概念をまとめる。 大きなファイルは、それぞれが 1 つの概念を担うモジュールに分割してください。
3. 重複する概念をまとめる。 2 つの型、関数、定数の内容が大きく重複している場合は、統合してください。読者が把握すべき概念は、少ないほどよいです。
4. 共通コードを使う。 ファイルパスの解析など、共通のユーティリティがすでにコードベースに存在する場合があります。独自に実装する前に、ライブラリやユーティリティ関数がないか確認してください。
5. 導出可能性。 すでにスコープ内にある値から計算できる値は、別途渡したり保存したりしないでください。導出可能な状態を取り除くと、シグネチャ、型、制御フローが一度に簡潔になることがあります。例：isDirty パラメーターが常に editorContent !== baseline で求められるなら、省略できます。

過剰適合

コードは、それ単独で理解できるものでなければなりません。会話やこの PR を見ていた人にしか分からない変更は、過剰適合です。経緯を知らない読者に向けて書いてください。

• 名前やコメントの意味を理解するのに会話の内容が必要なら、コードベースで使われている用語に沿って書き直してください。
• 未リリースのコードとの後方互換性を保たない。 同じブランチの以前の段階にしか存在しなかった古いシグネチャ、エイリアス、データ形式への対応は、リリースされていないものとの互換性です。その古い経路を削除し、呼び出し元を更新してください。