simplify-code

简化代码

在不改变行为的前提下，提升代码的清晰度、一致性和可维护性。遵循项目的本地约定。改进后的代码应更易于阅读、调试和维护，且范围不应超出原始代码。

范围

• 用户提供所选代码或带标签的代码时，使用这些代码。
• 用户指定目标文件、目录或描述时，使用指定内容。
• 用户要求进行常规简化但未指定目标时，先检查暂存的源代码更改；如果没有暂存内容，再检查未暂存的源代码更改。
• 将编辑限制在目标或差异中涉及语言的源代码文件；一个仓库可能包含多种语言。根据目标文件、附近代码、项目布局和构建配置推断语言；不要将任何扩展名列表视为完整清单。
• 除非用户明确要求编辑，否则不要将文档、JSON、YAML、锁文件、图片及其他非代码文件纳入简化范围。
• 过滤后若没有剩余源代码文件，则说明没有可简化的内容，并且不做任何更改。

工作流程

1. 确定目标代码。

   • 编辑前，阅读相关文件、本地约定和附近的代码模式。
   • 理解外部可观察到的行为：输入、输出、副作用、错误处理、渲染结果、无障碍语义、持久化、公共 API 形式、序列化、顺序、时序和用户可见文本。
   • 更改微妙逻辑前，查看附近的测试或示例；如有，用它们来确认行为。
   • 简化刻意设计的复杂逻辑前，查看 ADR、设计文档和约束注释。在本次处理中保留已记录的决策。
   • 注意任何歧义；基于合理假设继续，只有在错误猜测可能改变可观察行为时才暂停并询问。

2. 寻找有意义的简化方式。

   • 减少不必要的分支、嵌套、重复和间接层。
   • 缩小状态作用范围，同时保留行为。优先使用返回值而非可变状态、局部变量而非字段、字段而非模块状态。通过推导值代替维护同步副本。新读者无需搜索，就应能回答“X 从哪里来？”和“什么会改变 X？”。
   • 删除死代码：可证明无法到达的分支、未使用的符号和未使用的参数。仍可能触发的守卫条件属于行为——除非证明其不可达，否则应保留。
   • 当分支仅有少量载荷字段不同、主体几乎相同时，合并它们。
   • 避免嵌套三元表达式；存在多个条件时，使用 switch 或 if/else 链。
   • 对简单的二元或枚举情况，如果清晰易读，优先采用简洁直接的映射，例如 A -> x 和 B -> y。
   • 将相关逻辑归组；不同关注点应放在不同单元中。
   • 采用紧凑、避免重复的实现，但前提是代码依然清晰且易于调试；提取辅助函数若只会增加命名负担且没有复用价值，则将这类一次性的小决策保留在原处。
   • 采用最简单易读的形式；不要只为显得更明确而扩展代码。
   • 如果更好的名称符合项目既有术语，则改进含糊不清的变量、函数、属性或类型名称。
   • 仅在有具体收益时添加或移除抽象：降低复杂度、隔离行为、便于测试、实现复用或表达领域含义。具备上述任一价值的抽象都应保留。可考虑移除的对象包括只有一个调用方的包装器、没有第二种实现的适配器，以及为尚未使用的未来功能而引入的间接层。试着删除该单元：如果复杂度随之消失，它就只是透传层；如果复杂度会分散到多个调用方中，则应保留。
   • 如果重构会增加认知负担，却没有明确收益，就不要进行。
   • 删除解释显而易见的语法或控制流的注释，但保留解释意图、权衡、不变量或非显而易见行为的注释。
   • 仅当注释掉的代码显然是过时的杂项，且符合本地做法时才将其删除；否则保留，或提出询问。

3. 保持行为并遵循标准。

   • 保留所有原有功能、输出、副作用、错误、顺序和边界情况行为。
   • 保留外部可见的契约，例如公共 API、导出名称、类型契约、线格式、存储键、分析事件、错误文本、DOM 结构、ARIA 标签和对快照敏感的输出；除非用户明确要求更改，或本地测试和惯例表明它们属于内部内容且可以安全更新。
   • 遵循项目在语言惯例、模块和导入、类型或接口、组件、错误处理和命名方面的标准。
   • 在适用时遵循特定框架的标准，例如导入顺序、显式公共或顶层类型、组件属性模式和文件扩展名惯例。

4. 避免仅为外观而进行的改动。

   • 不要仅通过更改换行、文本折行、缩进、函数签名、参数列表或多行表达式的形式来重新格式化代码。
   • 让格式化工具处理格式。
   • 如果修改前后可读性相当，优先选择改动较少、差异较小的版本。

5. 验证结果。

   • 重新阅读修改后的代码，并与原始代码对比业务逻辑和外部可观察行为，包括细微的边界情况差异。
   • 运行可用的、范围最小且相关的检查，例如针对性测试、类型检查、代码检查或构建。
   • 如果无法运行检查，或检查范围对于此任务过大，请说明这一缺口。
   • 检查差异并移除无关改动。

输出

总结应与改动规模相称。对于小型任务，用 1–3 条具体要点或一小段文字说明改动内容及验证方式。

对于较大规模的工作，使用以下结构：

• 简化：每项简化列出受影响的文件。将三个调用方中的辅助函数提取出来算作一项简化。包含以下子项：
  • 修改前：旧结构或复杂性的来源
  • 修改后：新结构
  • 优势：可读性、可维护性、减少重复或降低认知负担
• 验证：列出运行的命令及结果，或说明未运行的检查。
• 范围：用一行列出检查过的文件，并说明哪些文件无需修改。

总结应具体，只包含有助于理解的重要改动。除非简化确实带来了这些结果且验证支持，否则不要声称行为发生了变化、性能有所提升或错误已修复。