本系列文章由 @yhl_leo 出品，转载请注明出处。
文章链接： http://blog.csdn.net/yhl_leo/article/details/50532701
名称所表达的含义极其丰富，你也许并不生活在对它们的恐惧中，不过绝不要低估名称的力量。
名称的重要性无可估量，作为程序员，我们在对各种构造进行命名时，将行使这项重大的权力。一个命名糟糕的实体，不仅很不方便，而且会产生误导，甚至非常危险。
一个对象名应该清晰地描述这个对象。
那么究竟应该如何进行命名呢？为对象命名的方式取决于你所遵循的任何编码标准。不过，虽然标准可能要求适用某种命名约定，但是并不会具体到足以指导如何为程序的每个部分都恰当地命名。
为了恰当地命名，在为每个对象相出名称之前，必须准确了解这个对象是什么！如果你都不知道你所命名对象是什么，它的用途和存在的理由也不清楚，那么你怎么能够赋予它一个有意义的名称呢？那么这样命名得到的实体，绝对是一个命名糟糕的实体。
好的对象名称往往具有以下四个品质：
- 技术上正确
- 符合语言习惯
- 描述性
- 恰当
下面我们逐一进行分析。
技术上正确
现代编程语言对于如何命名都规定了一些准则。以C/C++为例，最基础的四条原则是：
- 变量名只能是字母（
A-Z,a-z）和数字（0-9）或下划线_组成； - 第一个字母必须是字母或者下划线；
- 不能使用C/C++关键字来命名变量，以免冲突；
- 变量名区分大小写。
这里需要补充的是，在前两条原则下，命名对象可以是以下四种组合方式：纯字母（myName），或字母与数字的组合（myName1, m2n），或字母与下划线的组合（_myName, myName_, _myName_, …），或下划线与数字的组合（_1, _1_, …）。
还有一些其他技术限制，例如C/C++标准中预留了一些特定的名称：你不应该使用任何以str作为开头后面跟一个小写字母或者以下划线开头的全局标识符，以及任何名为std的命名空间中的标识符。知道这些限制，对于我们编写鲁棒和正确的代码非常重要。
符合语言习惯
仅仅因为一种语言允许某个特定的字符组合，并不能表示这个组合就是一个好的名称。清晰明了的名称，应该遵循读者所期望的约定，即各种语言习惯。某些语言具有一个公共命名约定，如庞大的Java库建立了一个不能忽视的先前技术（prior art），而C/C++等语言则没有这样一个通用命名约定。
虽然没有通用的命名约定，但是有些被业内广泛接受并认可的规则或约定，例如匈牙利命名法，Google C++编程命名约定，华为 C编程命名约定等，都是值得参考的
描述性
显而易见，名称必须是描述性的。这也是使用名称的原因，即用来描述某个事物。然而我们通常会见到一些令人迷惑的标识符，其含义与其描述的对象并不相符，甚至相悖。
即使是使用准确的名称也会有局限性。虽然说不要望文生义，但人们还是通常坚持他们对于一个概念最初的理解。因此，通过谨慎地命名来表达正确的第一印象非常重要。那么，就有必要从一个外行读者的角度来选择名称，而不是从一个内行的角度来选择。
有时，找到一个恰当的描述非常困难。如果你无法想出合适恰当的名称，那么你也许就要改变你的设计了。这往往是什么地方不对劲的征兆。
恰当
首先，是长度。虽然限制很多编程语言对于标识符的长度已不再有任何明显的限制了，但是这并不代表我们可以为了解释清楚对象的含义，而对其名称长度不加限制，随意设定。而要创建清晰明了，描述性的名称，那么就必须适用自然语言的词语。对于这些词语，程序员们都有一种内在的简写和缩短它们的欲望，但这有时也会造成令人困惑的杂乱名称。因此，过度冗余或缩减都是不可取的，例如适用a来代替apple_count显然不妥，但是使用apple_count_of_my_apple_funtion就显得非常傻。
进行命名时，重点在于清晰而非简洁。
其次，是格调。就像粗鲁的笑话在葬礼上非常不合时宜一样，欠考虑的名称也会破坏代码的职业性。有这么严重吗？是的。无聊的名称会使读者怀疑代码作者的能力。
应该记住，避免使用一些类似blah或wibble不严肃的名称，或者foo和bar等古怪的名称。它们很容易悄悄混入代码，虽然一开始人们会觉得挺有趣，但是以后会造成很多混乱。显而易见的是，职业化就意味着在命名时不要使用语气助词。
始终在第一次就给对象起好名字。
附上一些相关的内容：
- 匈牙利命名法：是一种有争议的命名约定，他将关于变量或函数的类型信息编入它们的名称，认为这样会使代码更易于阅读和维护。这种命名法最初是在20世纪80年代在Microsoft公司中出现，并在该公司的Win32 API和MFC中得到广泛使用，这也是这种命名法流行的主要原因。之所以被称为“匈牙利命名法”，是因为它的创始人是以为匈牙利程序员，Charles Simonyi。此外，变量名看起来好像是使用匈牙利语书写的，也是其得名的原因。
- 大写字母约定：大多是语言禁止我们在标识符中使用空白和标点，所以我们要采用一种约定来连接多个词语。这些大写字母的约定就像没完没了的“编辑器圣战”一样，使许多程序员相互拳脚相加。在现代的代码中你会看到很多常用的方法：
camelCase： 其在Jave语言库以及许多C++代码库中得到广泛应用。这种方法得名于其大写字母的布局很像骆驼的驼峰，并且可能是在20世纪70年代早期在Smalltalk中第一次使用的。ProperCase：这种方法与camelCase很接近，唯一的区别是其第一个字母也是大写的。有时这种方法有时也被成为PascalCase。这两种约定常常一起使用。例如Java语言的类名以ProperCase方式书写，而成员名则以camelCase方式书写。Windows API和.NET使用的是ProperCase。using_underscores：这种风格的支持者是C++标准库（看看所有std命名空间中的名称）和GUN Foundation的实现人员。
此外，还有很多其他形式。
- 良好的结尾：选择后缀是文件命名的一个组成部分，C/C++的编译器对于后缀没有要求，但是将头文件命名为
something.h是一种普遍约定，如果不这么做，就会想在你眼睛里钉钉子一样难受。由于缺乏严格的规定，我们确实感到有些痛苦，对于C++实现的文件名存在一些约定，如常见的后缀.C,.cc,.cpp,.cxx和.c++等。以.hpp为后缀的C++文件虽然不常见，但是也会遇到。你的选择可能取决于编译器，个人偏好或编码标准。关键是保持一致性。选择一种后缀方案，然后坚持使用下去。 - 不应做的：不要创建具有以下特征的名称：
- 含义模糊：方式有千万种，首字母缩略和简写会显得很随意，而单个字母的名称则太神秘。
- 啰嗦：避免使用过于简洁的名称，但是也不有创建像
the_number_of_apples_before_I_start_eating这样的变量，这样既无趣又无聊。 - 不准确或使人误解：显而易见，应该使你的名称准确，另外错误的拼写会开辟出一块困惑的雷区。
- 有歧义或含糊不清：不要使用可以用多种方式解释的名称，例如使用
data或value这种含糊不清的名称，除非它们代表的是什么非常清楚；避免使用temp或tmp等含糊不清的名称，除非你真的必须这么做；不要通过大小写或单个字符来区分名称；不要无故创建其名称与外部范围某个对象相同的局部变量。 - 太做作：有趣的小缩写，很难记住的聪明的简写以及对数字的解释性使用都应该被避免。对于没有经验的人来说，
internationalization的一种常见缩写il8n看起来会显得毫无意义。应该创建清晰，具体，简洁，准确和无歧义的名称，使用公共的术语和参照标准。