代码命名方法论教练

代码命名：被忽视的隐性 bug 源

在代码 review 时，你可能会遇到这样的场景：

• 变量名 data、temp、info 无法表达其真实含义
• 布尔变量 status、active 存在歧义
• 函数名 handleData 或 processOrder 暗示着单一职责的违反
• 同一个概念在不同地方写作 userId 和 uid

这些问题并非风格偏好，而是实打实的技术债务。烂命名不是审美问题，而是隐性 bug 源——每一次阅读都需要重新推理代码意图，每一次修改都增加认知负担。

这套技能如何工作

代码命名方法论教练将命名视为可量化、可练习的工程技能，而非凭感觉的审美判断。

核心能力

• A/HC/LC 量化模型：用 Ambiguity（歧义）、High Context（高上下文）、Low Context（低上下文）三维度评估命名质量，而非主观判断
• 识别信号表：针对八类常见命名反模式提供可操作的修复建议：

- 模糊容器名 → 写出真正装什么（如 pendingInvoices 而非 data）
- 歧义布尔值 → 使用 is/has/can/should 前缀
- 嵌套循环变量 → 用 row/col/userIndex 提升可读性
- 多功能函数 → 拆函数或改名到单一职责

• 卡点自救流程：四步闭环的重命名流程：

1. 降级：把命名当作文写一句话描述「是什么/做什么」
2. 提示分层：先判断事物还是动作，再判断上下文高低，最后定前缀
3. 重做：两轮重命名对比阅读成本
4. 登记：团队高频歧义名收进词典，作为 review 检查项

关键步骤

在 PR 中实践时，技能提供具体的操作指引：

• 每次 PR 至少重命名 1 个模糊变量
• 每周做一次「命名走查」读旧代码
• 团队规范落地时，先定 10 条最高频规则 + 词典，再逐步扩展
• 铁律：不靠注释掩盖烂名；重命名先用工具安全重构；布尔必带 is/has/can

适用边界

命名无绝对标准，以团队约定与项目一致性为准。技能提供的是方法论框架而非一刀切的规则，具体语言惯例应参考官方风格指南作为补充。不提供任何作弊/代做手段，以真实代码质量提升为目标。