20变量名的力量_1

1. 选择好变量名的注意事项

1.1. 最重要的命名注意事项

​ 为变量命名时最重要考虑事项是，该名字要完全、准确地描述出该变量所代表的事物。获得好名字的一种实用技巧是用文字表达出变量所代表的是什么。

1.2 以问题为导向

​ 一个好的名字反映的通常都是问题，而不是解决方案。一个好的名字通常表达的是“什么”，而不是“如何”。例如，一条员工数据记录可以称作 employeeData 或者 inputRec ，前者表达的是“什么”，而后者表达的是“如何”，所以前者是个好名字。

1.3 最适当的名字长度

​ 当变量名的平均长度在 10 到 16 个字符的时候，是最合适的。例如“numteamMembers”、“teamMemberCount”、"numSeatsInStadium"、"seatCount"等。

1.4 作用域对变量名的影响

​ 短的变量名总是不好吗？不，不总是这样。当你把一个变量名取得很短的时候，如 i ,这一长度本身就是对该变量名做出了一些说明——也就是说，该变量代表的是一个临时的数据，它的作用域非常有限。

​ 对位于全局变量命名空间中的名字加以限定。

1.5 变量名中的计算值限定词

​ 很多程序都有表示计算结果的变量：总额、平均值、最大值等等。如果你要用类似 Total、Sum、Average、Max、Min 等这样的限定词来修饰 某个名字，那么请记住把限定词加到名字的最后。例如：revenueTotal、expenseTotal、expenseAverage 等。

​ 把计算的量放在名字最后的这条规则也有例外，那就是 Num 限定词的位置已经约定俗成的。Num 放在变量名的开始位置代表一个总数：numCustomers 表示的是顾客总数；Num 放在变量名的开始位置代表一个下标： numCustomer 表示当前顾客的序号。 然而，由于这样使用 Num 常常会带来麻烦，因此可能最好的办法是避开这些问题。用 Count 或者 Total 来代表顾客总数，用 Index 来代表某个特定的顾客。

1.6 变量名中的常用对仗词

begin/end
first/last
locked/unlocked
min/max
next/previous
old/new
opened/closed
visible/invisible
source/target
source/destination
up/down

2. 为特定类型的数据命名

2.1 为循环下标命名

​ 循环是一种极为常见的计算机编程特征，为循环中的变量进行命名的原则也由此因运而生。i、j 和 k 这些名字都是约定俗成的。

​ 如果一个变量要在循环之外使用，那么就应该为它取一个比 i、j 或者 k 更有意义的名字。

2.2 为状态变量命名

​ 为状态变量取一个比 flag 更好的名字。最好是把标记（flag）看做状态变量。标记的名字中不应该含有 flag，因为从中丝毫看不出该标记是做什么的。

​ 为了清楚起见，标记应该用枚举类型、具名常量或者作具名常量的全局变量来对其赋值。

2.3 为临时变量命名

​ 临时变量用于存储计算的中间结果，作为临时占位符，以及存储内务管理字。通常，临时变量是一个信号，表明程序员还没有完全把问题弄清楚。而且，由于这些变量被正式地赋予了一种“临时”状态，因此程序员会倾向于比其他变量更为随意地对待这些变量，从而增加了出错的可能。

2.4 为布尔变量命名

(1) 谨记典型的布尔变量名

• done 用 done 表示某件事情已经完成。这一变量可以用于表示循环结束或者一些其他的操作已经完成。在事情完成之前把 done 设为 false, 在事情完成之后把它设为 true。
• error 用 error 表示有错误发生。在错误发生之前把变量值设为 false, 在错误已经发生是把它设置为 true。
• found 用 found 来表明某个值已经找到了，在还没有找到该值的时候把 found 设置为 false, 一旦找到该值就把 found 设置为 true。
• success 或 ok 用 success 或者 ok 来表明一项操作是否成功。在操作失败的时候把该变量设置为 false， 在操作成功的时候把其值设置为 true.

(2) 给布尔变量服务隐含“真/假”含义的名字

​ 像 done 和 success 这样的名字是很不错的布尔变量名，因为其状态要么是 true，要么是 false; 某件事情完成了或者没有完成；成功或者失败。

​ 另一方面，像 status 这样的名字却是很糟糕的布尔变量名，因为它们没有明确的 true 和 false。

​ 有些程序员喜欢在他们写的布尔变量名前加上 Is。这样，变量名就变成了一个问题： isdone、isError、isFound？用 true 或者 false 回答问题也就为该变量给出了取值。这种方法的优点之一是它不能用于那些模糊不清的名字： isStatus? 这毫无意义。

2.5 为枚举类型命名

​ 在使用枚举类型的时候，可以通过使用组前缀，如 Color_ 和 Planet_来明确表示该类型的成员都同属于一个组。

​ c++11 中声明枚举时可以加上class 关键字，在使用枚举值的时候必须冠以枚举类型名。

2.6 为常量命名

​ 在具名常量时，应该根据该常量所表示的含义，而不是该常量所具有的数值为该抽象事物命名。FIVE 是个很糟的名字， CYCLES_NEEDED 是个不错的名字。

3. 命名规则的力量

3.1 为什么要要规则

• 要求你更多的按规矩行事

• 有助于在项目之间传递知识

• 有助于你在新项目中更快速地学习代码

• 有助于减少名字增生

• 弥补编程语言不足之处

• 强调相关变量之间的关系

3.2 何时采用命名规则

• 当多个程序员合作开发一个项目时

• 当你计划把一个程序转交给另一位程序员来修改和维护的时候

• 当你所在组织中的其他程序员评估你写的程序的时候

• 当你写的程序规模太大，以至于你无法在脑海里同时了解事情的全貌，而必须分而治之的时候

• 当你写的程序生命周期足够长，长到你可能会在把它搁置几个星期会几个月之后又重新启动有关该程序的工作时

• 当在一个项目中存在一些不常见的术语，并且你希望在编写代码阶段使用标准术语或者缩写的时候

3.3 正式程度

​ 通常,你所需的正式程度取决于为同一个程序而工作的人员数量、程序的规模，以及程序预期的生命期。对于微小的、用完即弃的项目而言，实施严格的规则可能就太没有必要了。