.net 体系命名指引
第二节 选词规则
原则一：选择易读性强的命名方式。
解释：当名称由多个单词组成时，以可读性最强的方式排列它们。
例子：当需要命名一个表格形式的视图容器成员变量时，使用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，而不是将成员和类型的名字起得一样。除非这个成员没有明显的语义，或者作为函数参数来说它的类型不重要。