编程5分钟，命名2小时！大神程序员都在用这套命名方法

在 软件中随处可见命名：要给变量、函数、参数、类和封包命名，还要给源代码及源代码所在目录命名，甚至还有jar文件、war文件和ear文件命名。

但是，看似简单的命名，也是让不少程序员头疼的问题。 有一些小伙伴，在进行变量命名的时候，对于自己熟悉的英文，可能还会用英文命名一下，如果需要命名的部分不会用英文表达，或许就直接用拼音了。

有的童鞋一下想不起来怎么命名，直接用拼音直接用aa，bb等这样没有任何代表意义的字母来命名，可读性非常差，可能自己今天写的，一个星期后回来再看，也忘记其具体代表的含义了。

因此，许多人在写代码之前，总会在想啊想啊，用什么命名法好呢？对于经常在C++、Java、Python等主流语言上切换的强迫症来说，换个语言换种命名风格简直不要太混乱。

既然有这么多命名要做，不妨做好它。本期内容中，异步君为大家带来了起个好名字应遵从的几条简单规则，一起来看看吧

— 01 —

名副其实

名副其实说起来简单。我们想要强调，这事很严肃。选个好名字要花时间，但省下来的时间比花掉的多。注意命名，而且一旦发现有更好的名称，就换掉旧的。这么做，读你代码的人（包括你自己）都会更开心。

变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。

名称d什么也没说明。它没有引起读者对时间消逝的感觉，更别说以日计了。我们应该选择指明了计量对象和计量单位的名称：

选择体现本意的名称能让人更容易理解和修改代码。下列代码的目的何在？

为什么难以说明上述代码要做什么事？里面并没有复杂的表达式，空格和缩进中规中矩，只用到三个变量和两个常量，甚至没有涉及任何其他类或多态方法，只是（或者看起来是）一个数组的列表而已。

问题不在于代码的简洁度，而在于代码的模糊度：即上下文在代码中未被明确体现的程度。上述代码要求我们了解类似以下问题的答案：

（1）theList中是什么类型的东西？

（2）theList零下标条目的意义是什么？

（3）值4的意义是什么？

（4）我怎么使用返回的列表？

问题的答案没体现在代码段中，可代码段就是它们该在的地方。比方说，我们在开发一种扫雷 游戏 ，我们发现，盘面是名为theList的单元格列表，那就将其名称改为gameBoard。

盘面上每个单元格都用一个简单数组表示。我们还发现，零下标条目是一种状态值，而该种状态值为4表示“已标记”。只要改为有意义的名称，代码就会得敏液到相当程度的改进：

注意，代码的简洁性并未被触及。运算符和常量的数量全然保持不变，嵌套数量也全然保持不变，但代码变得明确多了。

还可以更进一步，不用int数组表示单元格，而是另写一个类。该类包括一个名副其实的函数（称为isFlagged），从而掩盖住那个魔术数[1]。于是得到函数的新版本：

只要简单改一下名称，就能轻易知道发生了什么。这就是选液含用好名称的力量。

— 02 —

避免误导

程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词，例如，hp、aix和sco都不该用作变量名，因为它们都是Unix平台或类Unix平台的专有名称。即便你是在编写三角计算程闹拿笑序，hp看起来是一个不错的缩写[2]，但那也可能会提供错误信息。

别用accountList来指称一组账号，除非它真的是List类型。List一词对程序员有特殊意义。如果包纳账号的容器并非真是一个List，就会引起错误的判断。

所以，用accountGroup或bunchOfAccounts，甚至直接用accounts都会好一些。

提防使用外形相似度较高的名称。例如，想区分模块中某处的XYZControllerFor-EfficientHandlingOfStrings和另一处的XYZControllerForEfficientStorage-OfStrings，会花多长时间呢？这两个词的外形实在太相似了。

以同样的方式拼写出同样的概念才是信息。拼写前后不一致就是误导。我们很享受现代Java编程环境的自动代码完成特性。键入某个名称的前几个字母，按一下某个热键组合（如果有的话），就能得到一列该名称的可能形式。

假如相似的名称依字母顺序放在一起，且差异很明显，那就会相当有助益，因为程序员多半会压根不看你的详细注释，甚至不看该类的方法列表就直接看名字挑一个对象。

误导性名称真正可怕的例子，是用小写字母l和大写字母O作为变量名，尤其是在组合使用的时候。当然，问题在于它们看起来完全像是常量“壹”和“零”。

读者可能会认为这纯属虚构，但我们确曾见过充斥这类名称的代码。有一次，代码作者建议用不同字体写变量名，好显得更清楚些，但前提是这种方案得要通过口头和书面传递给未来所有的开发者才行。后来，只是做了简单的重命名 *** 作，就解决了问题，而且也没引起别的问题。

— 03 —

做有意义的区分

如果程序员只是为满足编译器或解释器的需要而写代码，就会制造麻烦。例如，因为同一作用范围内两样不同的东西不能重名，你可能会随手改掉其中一个的名称，有时干脆以错误的拼写充数，结果就会出现在更正拼写错误后导致编译器出错的情况。

光是添加数字系列或是废话远远不够，即便这足以让编译器满意。如果名称必须相异，那么其意思也应该不同才对。

以数字系列命名（a1、a2…aN）是依义命名的对立面。这样的名称纯属误导——完全没有提供正确信息，没有提供导向作者意图的线索。试看：

如果参数名改为source和destination，这个函数就会像样许多。

废话是另一种没意义的区分。假设你有一个Product类，如果还有一个名为ProductInfo或ProductData的类，那它们的名称虽然不同，意思却无区别。Info和Data就像a、an和the一样，是意义含混的废话。

注意，只要体现出有意义的区分，使用a和the这样的前缀就没错。例如，你可能把a用在域内变量，而把the用于函数参数[5]。但如果你已经有一个名为zork的变量，又想调用一个名为theZork的变量，麻烦就来了。

废话都是冗余。variable一词永远不应当出现在变量名中。table一词永远不应当出现在表名中。NameString会比Name好吗？难道Name会是一个浮点数？如果是这样，就违反了关于误导的规则。

设想有一个名为Customer的类，还有一个名为CustomerObject的类，它们的区别何在呢？哪一个是表示客户 历史 支付情况的最佳方式？

有一个应用反映了这种状况。为当事者讳，我们改了一下，不过犯错的代码的确就是这个样子：

程序员怎么知道该调用哪个函数呢？

如果缺少明确约定，那么变量moneyAmount与money就没区别，customerInfo与customer没区别，accountData与account没区别，theMessage也与message没区别。要区分名称，就要以读者能鉴别不同之处的方式来区分。

— 04 —

使用读得出来的名称

人类长于记忆和使用单词。大脑的相当一部分就是用来容纳和处理单词的。单词能读得出来。人类的大脑中有那么大的一块地方用来处理言语，若不善加利用，实在是种耻辱。

如果名称读不出来，讨论的时候就会像个傻鸟。“哎，这儿，鼻涕阿三喜摁踢（bee cee arr three cee enn tee）[6]上头，有个皮挨死极翘（pee ess zee kyew）[7]整数，看见没？”这不是小事，因为编程本就是一种 社会 活动。

有一家公司，程序里面写了一个genymdhms（生成日期，年、月、日、时、分、秒），他们一般读作“gen why emm dee aich emm ess”[8]。我有见字照拼读的恶习，于是开口就念“gen-yah-mudda-hims”。

后来好些设计师和分析师都有样学样，听起来傻乎乎的。我们知道典故，所以会觉得很 搞笑 。 搞笑 归 搞笑 ，实际是在强忍糟糕的命名。在给新开发者解释变量名的意义时，他们总是读出傻乎乎的自造词，而非恰当的英语词。比较

现在读起来就像人话了：“喂，Mikey，看看这条记录！生成时间戳（generation timestamp）[9]被设置为明天了！不能这样吧？”

— 05 —

使用可搜索的名称

对于单字母名称和数字常量，有一个问题，就是很难在一大篇文字中找出来。

找MAX_CLASSES_PER_STUDENT很容易，但想找数字7就麻烦了，它可能是某些文件名或其他常量定义的一部分，出现在因不同意图而采用的各种表达式中。如果该常量是个长数字，又被人错改过，就会逃过搜索，从而造成错误。

同样，e也不是一个便于搜索的好变量名，它是英文中最常用的字母，在每个程序、每段代码中都有可能出现。由此而见，长名称胜于短名称，搜得到的名称胜于用自造编码代写就的名称。

窃以为单字母名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应 [N5]。若变量或常量可能在代码中多处使用，则应赋予其便于搜索的名称。再比较：

注意，上面代码中的sum并非特别有用的名称，不过至少搜得到它。采用能表达意图的名称，貌似拉长了函数代码，但要想想看，WORK_DAYS_PER_WEEK比数字5好找得多，而列表中也只剩下了体现作者意图的名称。

— 06 —

避免使用编码

编码已经太多，无谓再自找麻烦。把类型或作用域编进名称里面，徒然增加了解码的负担。没理由要求每位新人都在弄清要应付的代码之外（那算是正常的），还要再搞懂另一种编码“语言”。这对解决问题而言，纯属多余的负担。带编码的名称通常也不便发音，容易打错。

匈牙利语标记法

在往昔名称长短很重要的时代，我们毫无必要地破坏了不编码的规矩，如今后悔不迭。Fortran语言要求首字母体现出类型，导致了编码的产生。BASIC语言的早期版本只允许使用一个字母再加上一位数字。匈牙利语标记法[10]（Hungarian Notation，HN）将这种态势愈演愈烈。

在Windows的C语言API的时代，HN相当重要，那时所有名称要么是一个整数句柄，要么是一个长指针或者void指针，要不然就是string的几种实现（有不同的用途和属性）之一。那时候编译器并不做类型检查，程序员需要匈牙利语标记法来帮助自己记住类型。

现代编程语言具有更丰富的类型系统，编译器也记得并强制使用类型。而且，程序员趋向于使用更小的类、更短的方法，好让每个变量的定义都在视野范围之内。

Java程序员不需要类型编码，因为对象是强类型的，代码编辑环境已经先进到在编译开始前就能监测到类型错误的程度！所以，如今HN和其他的类型编码形式都纯属多余。它们增加了修改变量、函数或类的名称或类型的难度，它们增加了阅读代码的难度，它们制造了让编码系统误导读者的可能性。

成员前缀

也不必用m_前缀来标明成员变量。应当把类和函数做得足够小，以消除对成员前缀的需要。你应当使用某种可以高亮或用颜色标出成员的编辑环境。

此外，人们会很快学会无视前缀（或后缀），而只看到名称中有意义的部分。代码读得越多，眼中就越没有前缀。最终，前缀变作了不入法眼的废料，变作了旧代码的标志物。

接口和实现

有时也会出现采用编码的特殊情形。比如，你在做一个创建形状用的抽象工厂（Abstract Factory），该工厂是一个接口，要用具体类来实现。你怎么来命名工厂和具体类呢？IShapeFactory和ShapeFactory吗？我喜欢不加修饰的接口。前导字母I被滥用到了说好听点儿是干扰，说难听点儿根本就是废话的程度。

我不想让用户知道我给他们的是接口，而就想让他们知道那是一个ShapeFactory。如果在接口和实现中必须选其一来编码的话，我宁肯选择实现。ShapeFactoryImp，甚至是丑陋的CShapeFactory，都比对接口名称编码好。

-END-

代码整洁之道

作者： [美] 罗伯特·C. 马丁（Robert C. Martin）

译者： 韩磊

内容简介：

软件质量，不但依赖架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。

本书提出一种观点：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，本书作者给出了一系列行之有效的整洁代码 *** 作实践。这些实践在本书中体现为一条条规则（或称“启示”），并辅以来自实际项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。

本书阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。

几种常见的程序命名规则

正确并形象地给函数、变量命名，不仅可以增加程序的可读性，也是程序员编程风格的一种反映。较好的命名习惯，可以有效的提高程序的可维护性。以下介绍几种常用的变量命名规则。

一、匈牙利命名法：广泛应用桐信哗于Microsoft Windows这类环境中。

这种命名技术是由一位能干的 Microsoft 程序员查尔斯·西蒙尼(Charles Simonyi) 提出的。匈牙利命名法通过在变量名前面加上相应的小写字母的符号标识作为前缀，标识出变量的作用域，类型等。这些符号可以多个同时使用，顺序是先m_（成 员变 量），再指针，再简单数据类型，再其他。例如：m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。

匈牙利命名法关键是：标识符的名字以一个或者多个小写字母开头作为前缀；前缀之后的是首字母大写的一个单词或多个单词组合，该单词要指明变量的用途。

例如：bEnable, nLength, hWnd。

匈牙利命名法中常用的小写字母的前缀局行：

前缀 类型 描述

a Array 数组

b BOOL 布尔

by BYTE 无符号字符

c char 字符

cb Count of bytes 字节数

cr Color reference value 颜色值

cx,cy Count of x,y(short) 长度

dw DWORD 双字(无符号长整形)

f Flags 标志

fn Function 函数

g_ Global 全局的

h HANDLE 句柄

i Integer(int) 整数

l Long(long) 长整数

lp Long point 长指针

m_ Data member of a class 类的数据成员

n Short(short) 短整型

np Near point 短指针

p Point 指针

s String 字符串

sz Zero terminated string 以0结尾的字符串

tm Text metric 文本规则

u Unsigned int 无符号整数

ul Unsigned long(ULONG) 无符号长整数

w WORD 无符号短整数

x,y x,y coordinates(short) 坐标

v Void 空

有关项目的全局变量用g_开始，类成员变量用m_。

前缀 类型 例子

C 类 CDocument, CPrintInfo

m_ 成员变量 m_pDoc, m_nCustomers

g_ 全局变量 g_Servers

二、驼峰命名法：近年来越来越流行。

驼峰命名法，正如它的名称所表示的那样，指的是混合使用大小写字母来构成标识符的名字。其中第一个单词首字母小写，余下的单词首字母大写。

例如：

printEmployeePaychecks()

函数名中每一个逻辑断点都有一个大写字母来标记。

三、帕斯卡（Pascal）命名法：与驼峰命名法类似。

只不过驼峰命名法是第一个单词首字母小写，而帕斯卡命名法则是第一个单词首字母大写。因此这种命名法也有人称之为“大驼峰命名法”。

例如：

DisplayInfo()

UserName

都是采用了帕斯卡命名法。

在C#中，以帕斯卡命名法和骆驼命名法居多。

事实上，很多程序设计者在实际命名时会将驼峰命名法和帕斯卡结合使用，例如变量名采用驼峰命名法，而函数采用帕斯卡命名法。

四、下划线命名法。

下划线法是随着C语言的出现流行起来的，在UNIX/LIUNX这样的环境，以及GNU代码中使用非常普遍。

4.1 函数的命名

函数名使用下划线分割小写字母的方式命名：

设备名_ *** 作名()

*** 作名一般采用：谓语（此时设备名作为宾语或者标明 *** 作所属的模块）或者谓语 宾语/表语（此时设备名作为主语或者标明 *** 作所属的模块） 等形式，如：

tic_init()

adc_is_busy()

uart_tx_char()

中断函坦答数的命名直接使用 设备名_isr() 的形式命名，如：

timer2_isr()

4.2 变量的命名

变量的命名也采用下划线分割小写字母的方式命名。命名应当准确，不引起歧义，且长度适中。如：

int length

uint32 test_offset

单字符的名字也是常用的，如i, j, k等，它们通常可用作函数内的局部变量。tmp常用做临时变量名。

局部静态变量，应加s_词冠（表示static），如：

static int s_lastw

全局变量（尤其是供外部访问的全局变量），应加g_词冠（表示global），如：

void (* g_capture_hook)(void)

4.3 常量及宏的命名

采用下划线分割大写字母的方式命名，一般应以设备名作为前缀，

防止模块间命名的重复。如：

#define TIMER0_MODE_RELOAD2

#define TIMER2_COUNT_RETRIEVE(val)((uint16)(65536 - (val)))

当然，看作接口的宏可以按照函数的命名方法命名，例如：

#define timer2_clear() (TF2 = 0)

#define timer0_is_expired()(TF0)

据考察，没有一种命名规则可以让所有的程序员赞同，程序设计教科书一般都不指定命名规则。命名规则对软件产品而言并不是“成败悠关”的事，我们不要化太多精力试图发明世界上最好的命名规则，而应当制定一种令大多数项目成员满意的命名规则，并在项目中贯彻实施。

简言之，根据语意来选择词汇，别无它法……然而，有时我们会不知用什么词汇更合适。

当你想到某个抽象的东西，你更倾向于最先想到的词语，除非你故意不这样，这些词也会抢着出现，直到模糊或改变你的想法。

当你想到一个具体的对象，你觉得词穷，然后你想描述的已经看到了，然后你继续寻找更适合它的词。

哈哈，命名竟成了编程中最难的事~

Martin Fowler曾经在一篇文章中曾经引用过Phil Karlton的话：

There are only two hard things in Computer Science: cache invalidation

and naming things.

他说这句话在很长的一段时间内都是他最喜欢的话。可见命名对于广大的程序员来说的确是个大问题。

对于我们中国人来说，问题可能出在两个方面：

– 自打学编程开始就没被教育过要重视命名。

这可以在谭浩强的《C语言入门》一书中可见一斑。《C语言入门》可以说是很多程序员在大学时学习的第一门编程语言使用的教材。而本书通篇都是各种

a,b,c，x,y,z 的命名方式。这种poor naming的方式被广大程序员纷纷效仿，导致如今在很多项目代码中随处可见。

– 命名需要一定的英文功底，而国内程序员的英文水平参差不齐。

很多程序员被教育后开始逐渐重视命名，但是受限于英文水平，不知道使用什么合适的英文词汇来命名。有的甚至直接把中文直译为英文绝基派的方式命名，或者直接用拼音来命名，反而得不偿失。

命名的重要性我锋斗想不需要过于强调。如今的软件开发早已不是求伯君那种单q匹马的时代。你写下的每一行代码都会在不久的以后被团队的其他人甚至你自己多次查看。如果是个开源项目，那么更会被全球各地的人查看源代码。所以代码的可读性就变得尤为重要。如果读者能够轻松读出你的代码的意并贺图，那么就说明你的命名功底相当扎实。

比如在一个管理系统中，你使用这样的代码： a = b * c

很容易让人摸不着头脑，虽然程序能够正常运作，但恐怕没人敢轻易修改这行他们不了解的代码。而如果修改成为这样： weeklypay =

hours_worked * pay_rate那恐怕极少有人不懂这行代码的意图。

糟糕的命名也会导致大量无谓的注释，这是一个很容易跳进去的陷阱。下一段代码怕别人不明白你的意图，那么就加上注释。这貌似是一个很精妙的想法，实际上却南辕北辙。比如以下的注释：

int d// elapsed time in days

貌似很容易让人读懂，但是问题还是很多。首先注释不能跟着所有的引用，在定义处了解了d的含义，继续往下看的话却很容易忘记；其次代码更新了，很可能会忘记修改注释，反而给把读者带入歧途。

与其用这样的注释，还不如直接重命名： int elapsedTimeInDays这样清晰易懂，还不用维护注释，何乐而不为？

那么如何着手来提高的自己的命名技巧那？

首先寻找一份公认的代码规范，并严格按照这样的标准执行。比如google开源了自己内部使用的语言编码规范，我们可以直接拿来使用。比如请看Google

Java的style guide，相当详实。除此之外还有C++等。这里收集了Google对各种语言的编码规范，非常具有参考价值。

标准的代码规范中的每一条都是有胜出的理由，值得我们遵从。但某些命名问题不一定只有一种最好的解决方式，这就需要团队自己建立起约定。比如对于Java单元测试类的命名方式，不同的团队可能不一样。比如有的团队喜欢以should开头，有的喜欢test开头，有的喜欢骆驼命名法，有些喜欢下划线命名法，每种方式有各自的利弊，没有一种能完全脱颖而出，所以需要团队自行制定。一旦确定使用某一种，那么一定要保持一致。

某些命名规范其实是可以进行自动化检查的，比如在Java应用的构建过程中可以引用checkStyle这款插件，对命名进行一些基本的检查，比如方法名、变量名是否遵循了一定模式等。这样在一定程度上可以强制大家遵守某些约定。自己以前曾经写过一篇文章，请参见这里。

最后要在团队中建立起code review的机制，通过code

review来相互监督纠正命名问题，并且这样更容易达成一致的命名约定，方便协作开发。code

review可以采取非正式会议评审的方式。最简单的方式就是每天找个固定时间大家一起聚在一个显示器前review每个人的代码，现场提出问题，当事人记录下来会后更改。这种方式非常高效。另外有的团队在嵌入代码时可能会引入一些代码评审机制，比如pull

request， cherry pick等。这种review方式比较重量级，反馈周期也较长，好处是可以保证最终迁入的代码是没有问题的。

很多语言和框架为了更加可读，都把命名玩出花来了。比如JavaScript生态圈中重要的单元测试工具Jasmine把测试函数以it命名，这样可以与参数连接起来成为一种表意的自然语言：

如何优雅地为程序中的变量和函数命名？

- 不同的代码段采用不同的命名长度。通常来说，循环计数器（loop

counters）采用1位的单字符来命名，循环判断变量（condition/loop

variables）采用1个单词来命名，方法采用1-2个单词命名，类采用2-3个单词命名，全局变量采用3-4个单词命名。

- 对变量采用具体的命名（specific names）方式，”value”, “equals”,

“data”在任何情况下都不是一种有效的命名方式。

- 采用有意义的命名（meaningful names）。变量的名字必须准确反映它的含义和内容。

- 不要用 o_, obj_, m_ 等前缀命名。变量不需要前缀标签来表示自己是一个变量。

- 遵循公司的变量命名规则，在项目中坚持使用同一种变量命名方式。例如txtUserName, lblUserName,

cmbSchoolType等，否则会对可读性造成影响，而且会令查找/替换工具（find/replace tools）不可用。

- 遵循当前语言的变量命名规则，不要不统一（inconsistently）地使用大/小写字母。例如：userName, UserName,

USER_NAME, m_userName, username, …。

以Java为例:

* 类名使用驼峰命名法（Camel Case）：VelocityResponseWriter

* 包名使用小写：com.company.project.ui

* 变量使用首字母小写的驼峰命名法（Mixed Case）：studentName

* 常量使用大写:MAX_PARAMETER_COUNT = 100

* 枚举类（enum class）采用驼峰命名法，枚举值（enum values）采用大写。

* 除了常量和枚举值以外，不要使用下划线’_’

- 在同一个类不同的场景（contexts）中不要复用变量名。例如在方法、初始化方法和类中。这样做可以提高可读性和可维护性。

- 不要对不同使用目的的变量使用同一个变量名，而是赋予它们不同的名字。这同样对保持可读性和可维护性很重要。

- 变量名不要使用非ASCII字符（non-ASCII chars）。这样做可能会在跨平台使用时产生问题。

-

不要使用过长的变量名（例如50个字符）。过长的变量名会导致代码丑陋（ugly）和难以阅读（hard-to-read），还可能因为字符限制在某些编译器上存在兼容性问题。

- 仅使用一种自然语言（natural language）来命名变量。例如，同时使用德语和英语来命名变量会导致（理解）不一致和降低可读性。

- 使用有意义的方法名。方法名必须准确表达该方法的行为，在多数情况下以动词（verb）开头。（例如：createPasswordHash）

- 遵循公司的方法命名规则，在项目中坚持使用同一种方法命名方式。例如 getTxtUserName(), getLblUserName(),

isStudentApproved()，否则会对可读性造成影响，而且会令查找/替换工具不可用。

- 遵循当前语言的变量命名规则，不要不统一地使用大/小写字母。例如：getUserName, GetUserName, getusername,

…。

以Java为例:

* 方法使用首字母小写的驼峰命名法：getStudentSchoolType

* 方法参数使用首字母小写的驼峰命名法：setSchoolName(String schoolName)

- 使用有意义的方法参数命名，这样做可以在没有文档的情况下尽量做到“自解释（documentate itself）”

总之，命名问题只是整个编码规范中的一小部分，但是起的作用举足轻重，它是判断一个程序员是否专业的必要标准。

---