命名检查看什么
命名是最便宜的文档：名字是否表达意图、是否与领域术语和既有接口一致、名称长度是否与作用域匹配、控制流能否一眼读懂。命名问题不影响编译，却直接影响后来人的理解成本，因此值得评审时花一点注意力。
基本信息
| 检查对象 | 类名、函数名、变量名、参数名、配置项与文件名 |
|---|---|
| 判断标准 | 未来读者能否快速理解，而不是是否符合个人口味 |
| 一致性 | 与领域术语、既有 API 命名保持一致 |
| 长度原则 | 短作用域可用短名，长作用域需要更描述性的名称 |
逐项检查什么
- 名称说明是什么或做什么，而不是怎么实现。
- 与领域术语、既有接口命名保持一致，避免同义词混用。
- 短作用域可用短名，长作用域需要更描述性的名称。
- 可读性：清晰的直白写法优于炫技写法，三元嵌套与位运算要谨慎。
- 重构之后名称是否同步更新，别让名字描述旧行为。
常见命名问题
| 问题 | 表现 | 影响 |
|---|---|---|
| 缩写堆砌 | gtUsrIdx | 后来人必须反查含义 |
| 名实不符 | 重构后名称未同步 | 按名字理解会得到错误结论 |
| 同义词混用 | 一处叫 config，另一处叫 settings | 搜索与替换都不可靠 |
| 布尔语义不清 | flag、status 之类含糊名 | 条件判断读起来要靠猜 |
命名意见怎么提
- 给出替代名字而不只是说「这个名不好」：具体方案比抽象评价有用。
- 说明理由：读者会在哪里误解，或与哪个既有术语冲突。
- 非阻塞的小改进标上 nit：命名偏好不应卡住合并。
- 同一术语反复出现时，先在团队里统一说法，再改代码。
命名分歧别升级为品味之争：以「未来读者能否快速理解」为准绳。
自检法：遮住定义只看调用处，能否推断参数与返回值含义；需要跳回去看才知道时，名称还需要更明确。