命名规范(2)通用命名约定

单词的选择

　　对框架中标识符的名字来说，达到一目了然的效果很重要。标识符的名字应该能够清楚的表达每个成员是做什么，以及每个类型和参数代表什么。名字应该和应用场景、系统的逻辑组成或物理组成以及为人熟知的概念相对应，而不应该与技术或架构相对应。

　　要为标识符选择易于阅读的名字。

　　要更看重可读性，而不是简洁性。以前的编程语言标识符命名之所以简单，是因为那时候的PC内存和磁盘的空间都很小，大家不得不尽量的压缩，对于现在的PC，大家就没必要纠结这个问题了，所以相对于简洁性，可读性更重要。

　　不要使用下划线、连字符以及其他任何既非字母数字的字符。对于私有字段，我还是比较喜欢在标识符前加个下划线前缀。

　　不要使用匈牙利命名法（基本原则：变量名=属性+类型+对象描述）。在C和C++中这个命名方式比较常见。

　　避免使用与广泛使用的编程语言的关键字有冲突的标识符。虽然在C#中可以通过添加“@”前缀的方式将关键字作为标识符来使用，但在使用方法时，用转义序列要比不转义序列麻烦得多。在 asp.net MVC开发模式Razor 语法中，行内表达式（变量和函数）都是以“@”开头的。所以不建议用这个加“@”符号的命名方式。

使用单词缩写词和首字母缩写词

　　不要使用未被广泛接受的缩写词和单词首字母缩写词作为标识符名字的组成部分。那么什么才是广泛的被接受的缩写词呢，一种测试方式是，直接将该缩写词输入到搜索引擎中，如果返回的前几个结果都是和缩写词本意相关的结果，那么该缩写词就有资格被称为众所周知。

避免使用编程语言特有的名字

　　要给类型名使用语义上有意义的名字，而不要使用语言特有的关键字。

　　要使用CLR的通用类型，而不要使用语言特有的别名（如果除了类型之外，标识符没有其他的语义）。

　　要使用比较常见的名字，比如value和item，而不要重复类型的名字（如果除了类型之外，标识符没有其他的语义，且参数的类型无关紧要）。如：void Write(int value);

为已有API的新版本命名

　　当一个已有类型需要添加新的特性的时候，我们无法直接对已有类型的成员进行扩展或重载，为此，只能是通过添加不同名字的新成员。

　　要在创建已有API的新版本时使用与旧版API相似的名字。

　　要优先使用后缀而不是前缀来表示已有API的新版本。在写C#的扩展方法时，比较常用。

　　考虑使用全新但有意义的标识符，而不是随便给已有标识符加个前后缀。

　　要使用数字后缀表示已有API的新版本（如果已有API的名字是唯一有意义的名字，即它是一个工业标准，不适合添加后缀或改名）。

　　要在引入64位整数而非32位整数进行操作的新版本API时用“64”后缀。当已有32位的API存在时采用这种方式，对只有64位版本的全新API则不需要这样做。