第二节 选词规则

原则一：选择易读性强的命名方式。

解释：当名称由多个单词组成时，以可读性最强的方式排列它们。

例子：当需要命名一个表格形式的视图容器成员变量时，使用GridView可以比ViewGrid更清晰的定义这个变量。因为“View”既可以作为名词，也可以作为动词。当作为后者时，容易与函数命名的“动词+名词”模式搞混。

原则二：易读性优于缩略性。

解释：诚然使用较短的名称能够缩短每行代码的长度，但它不应该以牺牲易读性为前提。

例子：理科公式中很多量使用了单个西文字母表示，当需要将这些公式编程为函数时，这些量应该用其本来代表的实际意义来表示，至少也要用其读音来表示希腊字母。例如“ω”在某些公式中代表角度，这个量应该命名为Angle，至少也要命名为Omiga，而不是一个“w”。

原则三：尽量只用“英文字母和数字”的字符。

解释：即使某些语言允许使用除了英文字母和数字之外的字符来命名，也要少用。一定要用也要有统一的规则。

例子：为界面上的控件——“确定”按钮命名时，使用BtnConfirm已经能够清晰地分割“按钮”和“确定”两个语义。但是，有时Btn_Confirm这样的命名方式更快地传达出这是一个UI控件的成员，通常由模板生成的，不能自由删改。

原则四：彻底抛弃匈牙利命名法。

解释：使用帕斯卡命名法和驼峰命名法已经足够对付dot Net体系的程序元素。首先目前宇宙最强大的IDE——Visual Studio 2017已经能够非常娴熟地对付类型不匹配等早期错误。然后匈牙利命名法和帕斯卡命名法是完全冲突的。

例子：虽然不应该严格遵守匈牙利命名法，但是其中某些要素是可以吸收改造的。可以使用Is、Can等含有是否、能否语义的单词来代替b组合一个布尔型变量，如使用IsOpen而不是bOpen。

原则五：不使用被各种编程语言广泛作为关键字的单词。

解释：很明显这会和编程语言本身产生语义级别的冲突。需要注意的是，C#的关键字就有一百多个。

例子：readonly是关键字之一，所以表示一个只读的变量时，使用IsReadonly。

关于缩略语

不要自定缩略语。尤其是自定的缩略语会和已有的单词产生歧义。

尽量少使用缩略语，即使要使用缩略语，也要用被广泛接受的缩略语。

关于语言特有的命名

关注语义去命名而不是语言特性关键字。

例如GetLength、GetSize、GetCount是不同类里面的方法，返回的是一个整型的变量。这时使用前三者而不是GetInt更好。

使用一些常见的名字，如value或item，而不是将成员和类型的名字起得一样。除非这个成员没有明显的语义，或者作为函数参数来说它的类型不重要。

第一节 命名法与分词

帕斯卡命名法

所有单词的首字母大写

PascalCasing

只由一个单词构成

Seed

单词只由一个字母构成

CSharp

由两个单词的首字母缩写的词，都作大写

IPAddress

由大于两个单词的首字母缩写的词，只大写第一个字母

NbaStars

不是由首字母缩写的词，也只大写第一个字母

IdCard

驼峰命名法

除第一个单词首字母小写外，其余单词首字母大写

camelCasing

只由一个单词构成

value

单词只由一个字母构成

ePay

由两个单词的首字母缩写的词，都作小写

uiFramework

由大于两个单词的首字母缩写的词，都作小写

cssBuilder

不是由首字母缩写的词，都作小写

lvHolding

合成词的处理

计算机科学专业英语中，有很多常见的合成词。即能从一个单词中明显拆分出两个或以上的独立单词。

该合成词已被权威英语词典收录时，按一个单词处理

Password/password

否则按多个单词处理

UserName/userName

至于按哪本权威词典算，由组织内部决定，牛津、柯林斯等都可以。

美式英语偏好

由于编程语言由美国公司或组织发明、维护、贡献较多，且美式英语单词往往比英式英语更短，所以偏好使用美式英语词汇。

color colour

大小写敏感性

不同的语言对大小写敏感的支持不同。因此，不能以大小写的不同来区分不同的内容。