simplify

审查当前分支或用户指定范围内的更改。按以下标准执行，不得改变行为。只修改该范围内的代码，并在修改后运行相关的现有检查。

代码和注释中的选词

变量名、函数名和注释都属于文字。对每一处都应用 Orwell 的规则（《Politics and the English Language》）：

能用短词时，绝不用长词。

能删掉一个词时，就删掉它。

能用主动语态时，绝不用被动语态。

能想到日常英语表达时，绝不用外来语、科学术语或行话。

拉丁语系词汇（reconcile、coalesce、normalize、reconciliation）听起来技术化且抽象；盎格鲁-撒克逊词汇（prune、run、watch、stop、drop、walk）简短而具体。优先使用盎格鲁-撒克逊词汇。

命名

1. 一个概念用一个词，一个词表达一个概念。 保持词汇统一。如果 sync 表示“拉取远程更改”，就不能又用它表示“将编辑内容写入磁盘”；重命名其中一个。
2. 删掉上下文已表达的词。 名为 workspaceWatcher 的模块不需要 startNativeWorkspaceWatcher；watchWorkspace 就足以表达相同意思。
3. 复合名称通常是在找借口：

• ❌ lastObservedDiskContent 是一份需要辩护的规格说明
• ✅ baseline 是清晰易懂的描述

注释

用浅显的英语说明代码本身无法体现的约束，也就是为什么需要这段不明显的代码。

• ✅ 如果代码很复杂且实现方式不明显，就添加注释。
• ✅ 如果函数包含复杂行为或副作用，就添加文档注释。
• 🗑️ 如果注释是在叙述对话中的修改历史，就删除它。
• 🗑️ 如果注释只是复述一眼就能看出的代码行为，就删除它。

代码结构

1. 倒金字塔。 在文件中，把导出函数或重要函数放在前面，把辅助函数放在后面。不要把重点埋起来。
2. 相关概念优先于庞大文件。 将大文件拆分成各自负责一个概念的模块。
3. 合并重叠概念。 如果两个类型、函数或常量有大量重叠，就将它们合并。读者需要记住的独立概念越少越好。
4. 复用共享代码。 代码库中可能已有常用工具（如文件路径解析）。内联实现之前，先检查是否存在库函数或工具函数。
5. 可推导性。 如果某个值可由当前作用域内已有的值计算得出，就不要单独传递或存储它。删除可推导状态通常能一次简化签名、类型和控制流。例如，如果 isDirty 参数始终等于 editorContent !== baseline，就可以删掉它。

过度拟合

代码必须能够独立成立。如果某项更改只有看过它发生过程的人（例如这段对话、这个 PR）才能理解，那就是过度拟合。要为没有任何背景的读者编写。

• 如果某个名称或注释必须依赖对话才能理解，就根据代码库自身的词汇重新编写。
• 不必兼容尚未发布的代码。 如果旧签名、别名或数据形状只在同一分支的更早版本中存在，那么支持它就是在兼容从未部署过的内容。删除旧路径并更新调用方。