第十一章--变量名的力量

第十一章--变量名的力量

11.1--选择好变量名的注意事项

1.最重要的命名注意事项：该名字要完全、准确地描述出该变量所代表的事物。通常，对变量的描述就是最好的变量名。名字应该尽可能地明确，像x,temp,i这样的变量名可以用于多种目的，但没有提供足够信息，通常这种变量都是不好的命名。

2.以问题为向导：一个好记的名字反映的通常是问题，而不是解决方案。即一个好名字表达的是“什么”（what），而不是“如何”（how）。

3.最适合当的名字长度：太短的名字表达不了足够的信息，而太长的名字则难写，且使得程序结构变得模糊。研究表明，最恰当的名字长度在10到16个字母之间。

4.变量名对作用域的影响：短的变量名并不是总是不好的。短的变量名通常表示其作用范围非常有限，如局部变量、经常被用在循环中得变量i等。对于全局命名空间的名字加以限定词。如uiEmployee和dbEmployee表示两个不同命名空间下得雇员变量。

5.变量名中得计算值限定词：如总额Total、平均值average等限定词在修饰一个名词的时候，注意把他们加在名词的后面。约定好的一致性可以提高可读性，简化维护工作。

6.变量名中常用对仗词。如begin/end, first/last, locked/unlocked等。

11.2--为特定类型的数据命名。

1.为循环下标命名

（1）循环中，有些约定俗成的变量名：如i，j，k等。

（2）如果一个变量要在循环之外使用，则用比i，j等更有意义的名字。

（3）如果循环体中代码很长，或者有嵌套循环，那么就应该为循环下标娶一个有意义以点的名字，而不是简单的i，j等。

2.为状态变量命名

（1）为状态变量取一个比flag更好的名字。标记的名字中不应该有flag，而是应该用枚举类型、具名常量，或用作具名常量的局部变量来对其复制，而且其值应该与上面这些变量作比较。

3.为临时变量命名

通常，临时变量是一个信号，表明程序员还没有完全把问题弄清楚。因此，很随意将其命名为“temp”等，埋下安全隐患。把临时变量取个有意义的名字很有必要。

4.为布尔变量命名

（1）谨记典型的布尔变量名：如done表示事情完成；error表示有错误发生；found表示某个值已经找到了；success或ok则表示某一操作是否成功。

（2）给布尔变量赋予隐含“真/假”含义的名字。如把status改为error或者statusOK这样的名字为好。有的人喜欢在布尔变量名前面加上Is其实很糟糕，它降低了简单逻辑表达式的可读性。

（3）使用肯定的布尔变量名。

5.为枚举类型命名

（1）在使用枚举类型的时候，可以通过使用组前缀。如Color_ , Plant_ 来表示该类型的成员都同属于一个组。但是如果你的编程语言对枚举类型的处理很像类，那么就可以省略前缀，不然就成了Color.Color_Red, 将其改为Color.Red最好。

6.为常量命名

在具名常量时，应该使用该常量表示的含义，而不是该常量所具有的数值。

11.3--命名规则的力量

1.为什么要有规则。

（1）要求你更多地按规矩行事，集中精力关注代码的更重要的特征。

（2）有助于在项目之间传递知识。

（3）有助于你在新项目中更快速地学习代码。

（4）有助于减少名字增生，如给同一个对象取不同的名字。

（5）弥补编程语言的不足之处，如可以用规则来仿效具名常量和枚举类型。

（6）强调相关变量之间的关系。如果你的编程不支持对象，那么可以在变量前面加上前缀表示他们属于同一组等。

2.何时采用命名规则

（1）当多个程序员合作开发一个项目时。

（2）当你计划把一个程序交给另一个程序员时。

（3）当有人评估你的代码时。

（4）当你的程序生命周期足够长，长到你要把它搁置几个星期或几个月再看时。

（5）当在一个项目中存在一些不常见的属于，并且你希望使用标准术语或者缩写时。

3.正式程度

不同规则所要求的正式程度也有所不同。通常，正式程度取决于为同一程序而工作的人员数量、程序的规模以及程序预期的生命期。

11.4--非正式命名规则

1.与语言无关的命名规则的指导原则：

（1）区分变量和子程序

（2）区分类和对象

（3）标识全局变量：如加前缀g_

（4）标识成员变量：如加前缀m_

（5）标识类型声明：如加前缀t_

（6）标识具名常量：如全部设为大写字母

（7）标识枚举类型的元素：如加表示组的前缀e_或E_

（8）在不能保证输入参数只读的语言里标识制度参数。

（9）格式化命名以提高可读性。

2.混合语言编程的注意事项：可以对命名规则（以及格式规则、文档规则等）做出优化，以提高整体的一致性和可读性--即使这意味着优化后和某种语言的规则相冲突。

11.5--标准前缀

1.用户自定义类型缩写（UDT）如：

（1）ch代表字符

（2）doc代表文档

（3）pa代表段落

（4）scr代表屏幕区域

（5）sel代表选中范围

（6）wn代表窗体

2.语义前缀

语义前缀比UDT更进一步，它描述了变量或者对象是如何使用的。如p代表指针，first代表数组第一个元素；g代表全局变量；i代表数组下标等。

3.标准前缀的优点

（1）让你在一个程序或者类中需要记忆的名字更少了。

（2）能更为精确地描述一些含义比较模糊的名字。

（3）使名字变得更加紧凑。

（4）在用得编译器不能检查你所有的抽象数据类型的时候，标准前缀能帮助你准确地对类型做出判断。

  标准前缀的缺点是使得程序员可能忘掉给变量取一个有意义的名字。

11.6--创建具备可读性的短名字

1.缩写的一般指导原则

（1）使用标准的缩写

（2）去掉所有非前置元音，如computer变为cmptr等。

（3）去掉虚词and，or，the等。

（4）使用每个单词的第一个或者前几个字母。

（5）统一地在每个单词的第一、第二或者第三子字母后截断。

（6）保留每个单词的第一个和最后一个字母。

（7）使用名字中的每一个重要的单词，最多不超过三个。

（8）去掉无用的后缀，如ing，ed等。

（9）保留每个因接种最引人注意的发音。

（10）反复使用上面方法，直到单词减少到8到20个字符。

2.有关缩写的评论

下面是避免缩写带来的错误的一些建议：

（1）不要用从每个单词中删除一个字符的方式来缩写

（2）缩写要一致

（3）创建你能读出来的名字

（4）避免使用容易看错或者读错的字符组合

（5）使用词典来解决命名冲突

（6）在代码中用缩写对照表来解释极短的名字的含义

（7）在一份项目级的“标准缩写”文档中说明所有的缩写

（8）记住，名字对于代码读者的意义比对作者更重要

11.7--应该避免的名字

（1）避免使用令人误解的名字或缩写

（2）避免使用具有相似含义的名字

（3）避免使用具有不同含义但却有相似名字的变量

（4）避免使用发音相近的名字，比如wrap和rap

（5）避免在名字中使用数字

（6）避免在名字中拼错单词

（7）避免使用英语中常常拼错的单词

（8）不要紧靠大小写来区分变量名

（9）避免使用多种自然语言

（10）避免使用标准类型、变量和子程序的名字

（11）不要使用与变量含义完全无关的名字

（12）避免在名字中包含易混淆的字符