代码大全2——变量与命名——代码的可读性始于名字

核心观点
McConnell 全书反复强调一个前提：代码写一次，读一百次。而阅读的起点，就是每一个变量名、函数名、常量名。名字是代码与阅读者之间最频繁的界面。

关键要点

1. 名字要精确，而非含糊

名字应该回答三个问题：它是什么、干什么用、为什么存在。
避免空洞的通用词：data、info、value、temp、flag 单独出现时几乎毫无信息量。
用具体动词或名词替换：currentState 好于 data；isValid 好于 flag。
2. 长度与作用域成正比

短作用域（循环计数、局部临时量）可以用短名，i、j、n 完全够用。
作用域越大、生存期越长，名字应该越具体、越长：employeeCount 而非 cnt。
一个实用的经验法则：变量名长度大致与其「可见范围」匹配。
3. 命名要「读得出来」

名字应该能被人脑自然拼读，避免无意义的缩写和缩写混用。
全书建议：建立并遵守一份命名约定表，而不是每个人凭感觉缩写。缩写要么统一，要么不用。
4. 使用命名前缀表达意图（虽有过时争议，但精神可借鉴）

McConnell 主张用前缀（如 p 表指针、c 表常量）传递类型/属性信息。
现代实践中更推荐用清晰的「动词+宾语」表达语义，而非依赖前缀，但其核心思想——名字要携带额外语义——依然成立。
5. 常量和魔法数字

凡是出现两次以上、或含义不明确的具体数值，都应提取为具名常量。
好名字让「为什么是这个值」可被追踪：MAX_RETRY_COUNT = 3 比裸 3 强太多。
我的思考
这篇对我触动最大的是一句近乎废话却最易被忽视的话：「好的命名是最便宜的注释」。很多团队把精力花在写注释上，却不肯多花 5 秒想一个好名字。命名的收益是持续性的——它每次阅读都在生效，而注释往往在代码改动后失修。

落地建议：团队 code review 时，把「命名是否清晰」列为必查项，往往能低成本地提升整体代码质量。