用途
Clean Code 技能以 Robert C. Martin（Uncle Bob）的《Clean Code》原则为基础，目标是把“能运行的代码”转化为“整洁的代码”。其核心理念引用 Grady Booch 的话：“如果代码能被原作者之外的开发者阅读并增强，它就是整洁的。”
主要能力
该技能围绕以下方面提供原则性指导：
- 有意义的命名：使用能揭示意图的名称（如 elapsedTimeInDays 而非 d）；避免误导性名称（如实际是 Map 却叫 accountList）；做出有意义的区分（避免 ProductData 与 ProductInfo）；使用可发音、可搜索的名称；类名用名词，方法名用动词。
- 函数：函数应短小、只做一件事、保持单一抽象层级、使用描述性名称；参数以 0 个为理想、1–2 个可接受、3 个以上需要强理由；避免副作用。
- 注释：不要注释坏代码，而应重写；用代码表达意图，例如用 employee.isEligibleForFullBenefits() 替代带注释的位运算判断；保留合法、信息性、澄清性和 TODO 类注释，避免喃喃自语、冗余、误导、强制、噪音和位置标记类注释。
- 格式：采用“报纸隐喻”，高层概念在上、细节在下；相关代码行保持垂直密度；变量声明靠近使用位置；保持缩进以体现结构。
- 对象与数据结构：通过接口隐藏实现；遵循迪米特法则，避免 a.getB().getC().doSomething() 这类链式调用；区分数据传输对象（DTO）。
- 错误处理：使用异常而非返回码；先写 try-catch-finally 以界定操作范围；不要返回 null，也不要传递 null。
- 单元测试：遵循 TDD 三定律——在失败测试之前不写生产代码、单元测试只写到足以失败、生产代码只写到足以通过；并遵循 F.I.R.S.T. 原则（快速、独立、可重复、自验证、及时）。
- 类：类应短小并遵循单一职责原则（SRP）；采用逐步下降规则，使代码读起来像自上而下的叙述。
- 坏味道与启发式：识别僵化、脆弱、不可复用、黏滞、不必要的复杂度和重复等问题。
使用方式
资料给出典型使用请求示例：要求重构一段可运行代码，使名称更清晰、单元更小、错误更明确，同时保持行为不变，并用聚焦测试验证。技能还提供实现清单，用于自查：函数是否小于 20 行、是否只做一件事、所有命名是否可搜索且能揭示意图、是否通过让代码更清晰来避免注释、是否传入了过多参数、本次变更是否有失败测试等。
适用场景
资料明确列出四类场景：编写新代码时从一开始保证高质量；审查 Pull Request 时提供建设性、基于原则的反馈；重构遗留代码时识别并移除代码坏味道；改进团队标准时对齐行业最佳实践。
限制
仅在任务明确匹配上述范围时使用该技能。不要将输出视为针对具体环境的验证、测试或专家审查的替代。若缺少必要输入、权限、安全边界或成功标准，应停止并请求澄清。