代码大全第11章：变量名的力量

选择好变量名的注意事项

• 为变量命名时最重要的考虑事项是：名字要完全、准确地描述该变量表达的失误。
• 不过因此有些名字太长了。
• 以问题为导向，好记的名字反应的通常都是问题，而不是解决方案。
• 最适当的名字长度：太短的无法传达足够信息，太长的名字难写，也会使程序的视觉结构变得模糊不清。
• 变量名平均在10-16的程序最容易调试
• 当变量名取得很短时，本身就对该变量做出了一些说明，该变量代表临时数据，作用域有限，比如循环。
• 如果变量位于全局命名空间，最好加上限定词并避免产生冲突
• 类似表示计算结果的变量：Total，Sum，Average最好把这些词加到最后。
• 善用对仗词。

为特定类型数据命名

• 循环下标i，j，k等命名不要用在循环外。
• 状态变量应该用枚举类型或者具体名称的常量。
• 临时变量，尽量不要使用temp这个名字。
• 布尔变量，如done表示完成，error表示错误，success或ok表示操作成功。布尔变量名应该隐含『真/假』，且最好用肯定含义。
• 枚举类型，可以使用相同前缀表示该类型的成员都属于一个组。
• 常量命名，应该根据常量所表示的含义，而不是常量所具有的数值。

命名规则的力量

• 名字的符合特定规则更容易让你理解代码，举一反三。
• 当团队开发时，或者程序规模太大等时候，命名规则很有必要。
• 不同规则所要求的正式程度不同，取决于为同一项目工作的人员数量和程序规模。
• 用完即弃的项目，没有必要实施严格规则。多人协作的大型项目，无论开始阶段还是贯穿整个程序的生命周期，正式规则都是必不可少的。

非正式命名规则

• 区分变量名和函数名。
• 区分结构和该结构类型变量的名字。
• 格式化命名，比如用_分隔单词。
• 不要混用命名规则。

标准前缀

• 包括用户自定义类型（UDT）的缩写和语义前缀。

• UDT用很短的编码描述：
  

• 语义前缀比UDT更进一步，描述变量或者对象是如何使用的：
  
  

• 使用标准前缀能够精准描述一些含义比模糊的名字，也可以使名字更加紧凑。且可以协助判断，比如paReformat= docReformat很可能不对，因为两者拥有不同的UDT前缀。

• 标准前缀的主要缺陷是可能会让程序员产生惰性，不愿意再给变量起有意义的名字。

创建具备可读性的短名字

• 缩写的一般原则：
• 不建议使用语音缩写，比如before变成b4。
• 不要从每个单词删除一个字符的方式来缩写。要么多删点，要么别删。
• 缩写要保持一致，比如Num和No不要两个都用，也不要有些地方用缩写，有些用完整拼写。
• 创建可读的名字。
• 避免使用容易看错或读错的字符组合。
• 使用词典来解决命名冲突。
• 在文档中说明所有缩写的含义。
• 名字多于读者的意义要比对作者更重要。

应该避免的名字

• 避免使用令人误解的名字或缩写。
• 避免使用相似含义的名字。
• 避免使用名字相似但是含义不同的变量。
• 避免使用发音相近的名字。
• 避免在名字中使用数字。
• 避免在名字中拼错单词。
• 避免使用英文中容易拼错的词。
• 不要仅靠大小写区分变量。
• 避免使用多种自然语言。
• 避免使用标准库中保留字。
• 不要使用和变量含义完全无关的名字。
• 避免在名字中包含易混淆字符。