如何科学的为变量命名

一、变量命名的基本原则
1、变量命名的长度：控制在10至16个字符之间。
2、与语言无关的命名规则
标识全局变量：前面加上g_ 的前缀。在读到 g_RunningToatal 就会知道这个是全局变量。
标识成员变量：通过命名来判断出它既不是局部变量，也不是全局变量，比如 
在成员变量名的前面加上 m_ 前缀来表示是类的成员变量，以表明它是成员数据。
标识静态变量：前面加上s_ 的前缀。
标识枚举类型的元素：为枚举类型名增加 e_ 或者 E_ 前缀。
类似 Total、 Sum、 Average、 Max、 Min、 Record、 String、 Pointer 这样的表示计算结果的词语修饰某个变量时，请记住放在最后面。

/**
* 这组变量具有非常优雅的对称性。
*一致性，对称性，可以极大的提高可读性，简化维护工作。
*/
revenueTotal    revenueAverage
expenseTotal    expenseAverage
/**
*这组变量与上组变量相比，其对称性和可读性就很差。
*/
totalRevenue    averageRevenue   
totalExpense    averageExpense

给特定类型的数据命名
（1）为循环下标命名
i, j, k只能适用在非常简单的循环里，最多只能有几行。而且只能在循环之内用。 
总结为一句话： 尽可能的用比i, j, k更具体更形象的名字来命名。
（2）为状态变量命名
状态变量是用于描述你的程序的状态。绝大多数都是条件判断语句中的变量 。这里面最常用的反面例子就是经常在后面加个flag后缀。

/**
*命名模糊
*/
if(flag)...//这个flag表达的意识极其模糊
if(printFlag==10)...//同理，指代不清晰

/**
*命名清晰
*/
if(dataReady)...
if(printData==10)...

为临时变量命名
临时变量是用于存储计算的中间结果，作为临时占位符，以及存储内务管理值。 

一句话：把一个变量命名为temp, x,等临时的名字时，表明你还没有弄清楚它们的实际用途，或者是你当时找不到合适的名字命名，这本身就是可以改善的，百度谷歌一下，不行翻翻辞典，总是可以解决的。

为布尔变量命名
给布尔变量赋予隐含”真假”含义的名字； 
经典命名： 
done 在事情完成之前把done设为false,完成之后设为true 。
error 在错误发生之前把error设为false,在已经发生时设为true 。
found 在没有找到的时候把found设为false,一旦找到就设为true（在一个数组中查找某个值，在文件中搜寻某员工的ID等）。 
success或者ok 操作失败为false，操作成功时为true。
反面例子： 
status 没有明确的true和false的含义，true代表什么？false代表什么？每件事都有状态，所以这个命名是非常差的。

//一些程序员喜欢在前面加上 is.下面将进行比较：
if(done)            if(isDone)
if(error)           if(isError)      
if(found)           if(isFound)
/*
*很明显左边的命名方式要好于右边，if(isFound)的可读性和整洁性都要差于 if(found)
**/

为枚举类型命名
使用组前缀，如Color_ , Planet_ , Month_ 就可以了。如Color_Red, Color_Blue都是表示同属于一个组。

3、Java的命名规则
i 和 j 是整数下标。
常量全部大写，并用下画线分隔单词（ALL_CARS）。
类名和接口名中每一个单词的首字母要大写，包括第一个单词。
变量名和方法名中第一个单词的首字母小写，后面单词的首字母大写。
除用于全部大写的名字外，不使用下画线作为名字中的分隔符。
访问器子程序使用 get 和 set 前缀。

4、对如何加前缀的一些总结
语义前缀 含义
c 数量
first 数组中需要处理的第一个元素。针对当前操作而言的第一个元素
last 数组中需要处理的最后一个元素，与 first 相对应
g 全局变量
i 数组的下标
lim lim表示的是一个数组中并不存在的上界，lim 等于 last + 1
m 类一级的变量
max 数组或其他种类的列表中绝对的最后一个元素，反映的是数组本身
min 数组或其他种类的列表中绝对的第一个元素，与max相对应
p 指针

5、在给变量缩写时的一些原则
一个比较好的方法是去掉所有非前置元音。就是把一个单词里的除了首字母以外的元音全部去掉,举个例子：
computer 变成 cmptr 
screen 变成 scrn 
apple 变成appl 
integer 变成 intgr
去掉虚词and, or, the等。
保留每一个单词的第一个和最后一个字母。
去除无用的后缀—ing, end等。
确保不要改变变量的含义。

6、命名时应该避免的陷阱
避免在名字中使用数字。
避免使用具有相似含义的名字。
例如fileNumber 和 fileIndex 在语义上非常相似，如果把它们放在同一段代码里，就会很容易混淆它们。（有时候非常致命，找半天都发现不了错误）
避免在名字中包含易混淆的字符。例如：
1（数字 1）和 l（小写字母L） 
1和I（大写字母i） 
.和, 
0（零）和O（大写字母o） 
2（数字2）和Z 
;和: 
S和5 
G和6

二、变量命名的小tips
1.使用能够表达意图的名字
名字得能告诉我们它要做什么，为什么存在，以及是如何工作的。选择能够表达意图的名字，将更有利于我们理解代码。

int d; // 没有意义
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

在上面的片段中，我们不知道变量d指的是什么。于是阅读代码的人为了知道它的含义就不得不去寻找它的实例以获取线索。所以，要是我们能够好好命名这个变量，阅读代码的人就能够瞬间知道这变量的含义。
2.不要怕在选择名字上花时间
你应该多试几种不同的名字，直至足以描述其含义，千万不要害怕在这上面花时间。以后阅读你代码的人（包括你自己）将会因此而受益。此外，一个描述性的名称甚至还能有助于你在心中理清模块的设计。良好的命名的确需要花费时间，但是从长远来看，利大于弊。
3.重构名字
如果你在后面的开发过程中想到了一个更好的名字，那就不要犹豫，马上去改吧。现在的IDE使得重构名字变得异常容易。
4.避免在名字中出现干扰词
比如Manager、Processor、Data、Info以及“我不知道这叫什么”的同义词，都是干扰词。如果你需要使用上面这些干扰词的话，那么说明你的命名可能太累赘了。
5.小心难以命名的类/功能
一个很难命名的类或函数很有可能是一个代码异味。这说明：
代码做得太多。
代码做得还不够。
你对此问题理解得还不够透彻，需要先获取更多的信息。
6.类名
类应该有个名词或名词词组的名字，如Customer、WikiPage、Account和AddressParser。继承性父类应该给个又短又有冲击力的名字。子类的名字应该长点，通过形容词来描述其不同于它的父类之处，如SavingsAccount衍生于Account。
7.变量名
变量名也应该是名词。它们大多是由其指向的类衍生出去的。布尔变量应写成谓词的形式，如isEmpty和isTerminated，这样放到if语句才便于理解。
8.方法名
方法名应该是一个动词或动词词组，如postPayment()、deletePage()和save()。访问器和调整器应该分别前缀get和set。返回布尔值的方法应该前缀‘is’，如isPostable()，这样在if语句中才便于理解。
9.范围大小与变量名的长度
变量名的长度应和它的范围大小相匹配。如果变量的范围很短，那么变量名的长度也应该很短。反之，变量名则应该长一点，更有描述性。
10.范围大小与方法/类名的长度
对于方法和类名的长度则应该与其范围成反比。对于公共方法，短一点的名字会比较好，这是因为它们会被调用多次。私有方法只在类的范围内被调用，长一点的名字反而可以作为文档使用。此条规则的例外是派生类的名字。类越派生，基类前所加的形容词就越多，名字也就越长。
11.一个概念一个词
为某个抽象概念选定一个词，然后就不要变了。例如作为不同类中的等效方法，get()、fetch()和retrieve()会让人混淆起来。保持一致的词汇是程序员驾驭代码的重要工具。
12.不要将同一个词用于两个不同的概念
如果你遵循第11点——一个概念一个词的原则，那么就可以避免许多有着相同方法名的类。只要参数列表和各种方法的返回值在语义上是等价的就没问题。只有当你将同一个词用于两个不同的概念时才会出现问题。
例如，我们可以在多个类中使用add()方法，通过添加或连接两个现有的值来创建一个新的值。如果我们之后又需要在类中引入一个add方法用于添加参数到集合中，这就会因为语义不同而导致问题。这种新方法最好是改叫为insert()。
13.使用解决方案领域的名字
我们编写的代码今后可能会有其他程序员来阅读，所以我们使用一些技术术语进行代码命名会带来很大的好处。比如适当地使用算法名字、设计模式名字以及数学术语，这些命名方式很可能会让其他程序员更容易理解程序，引起共鸣。
14.使用问题领域的名字
如果实在找不到易于理解的技术术语来命名，那么也可以从问题领域来寻找合适的代码命名。当未来阅读你代码的程序员不确定代码意义的时候，这将为他们提供一些问题的线索。
不好的代码：

public class EntitiesRelation{
Entity o1;
Entity o2;
}

清晰的代码：

public class ProductWithCategory{
Entity product;
Entity category;
}

15.添加有意义的语境
大多数名字其本身是没有意义的，并且需要放到语境（类/函数/命名空间）中，才能让阅读代码的人理解它们指代的是什么。在某些情况下，可能需要前缀名称以补充语境。例如，假设我们有一些用来表示地址的变量：firstName、lastName、street、houseNumber、city、state和zip。如果只看state这个变量，我们是很难推断出它指的是什么意思，一个比较好的解决办法就是将这些变量封装到Address类中。
不好的代码：

string addressCity;
string addressHomeNumber;
string addressPostCode;

在大多数情况中，“邮政编码”（PostCode）是地址的一部分，很显然，邮政编码不能单独使用（除非你是在开发一个专门处理邮编的应用）。所以，没有必要在“PostCode”的前面加上“address”。而且，所有的这些信息都应该有一个上下文环境，在面向对象编程中，这里应该用一个“Address”类来表达这个地址信息。
清晰的代码：

class Address{
string city;
string homeNumber;
string postcode;
}

16.不要添加没来由的语境
只要意思明确，短一点的名字通常比长的好，所以不要多此一举地添加语境。名字前不应该被加缀一些可以从类/包/命名空间中推断的不必要的信息。
17.避免编码
鉴于现在的IDE的强大，我们已经不需要编码类型和范围信息到变量名和类名中。这包括不必添加至接口，因为使用代码的用户不需要知道他们的类正在向接口传递。所以如果你一定要使用编码，那么最好是对实现进行编码而不是接口。
18.避免错误的信息
不要给一些错误的信息，因为这样会误导阅读代码的人。如果你将一个实际支持数组的变量命名为accountList，那就很容易让人得出错误的结论。
19.使用读不出来的名字
编程是一个社会化的活动，使用那些读不出来的名字只会阻碍我们的讨论。
20.使用易搜索的名字
使用短而通用的名字会妨碍我们在代码库中搜索事物。这对我们操纵代码和重构很有影响。