《.NET 设计规范》第 3 章 命名规范

《.NET 规范》第 3 章 命名规范

3.1 大小写约定

　　要把 PascalCasing 用于由多个单词构成的命名空间、类型以及成员的名字。

　　要把 camelCasing 用于参数的名字。

　　要把两个字母的首字母缩写词全部大写，除非它是 camelCasing 风格的参数名的第一个单词。

　　要把由三个或三个以上字母组成的首字母缩写词的第一个字母大写。只有第一个字母大写，除非首字母缩写词是 camelCasing 风格的标识符的第一个单词。

　　不要把 camelCasing 风格的标识符头部的任何首字母缩写词的任何字母大写，无论首字母缩写词的长度是多少。

　　不要把所谓闭合形式的复合词中每个单词的首字母大写。

　　不要以为所有的编程语言都是区分大小写的，实际情况并非如此。不应该仅仅通过大小写来区分名字。

　　

3.2 通用命名约定

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

　　要更看重可读性，而不是更看重简洁性。

　　不要使用下划线、连字符以及其他任何既非字母数字的字符。

　　不要使用匈牙利命名法。

　　避免使用与广泛使用的编程语言的关键字有冲突的标识符。

　　不要使用缩写词和缩略词作为标识符名字的组成部分。例如，要使用 GetWindow，而不用 GetWin。

　　不要使用未被广泛接受的首字母缩写词，即使是被广泛接受的首字符缩写词，也只应该在必需的时候才使用。

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

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

　　要使用常见的名字，比如 value 或 item，而不要重复类型的名字 - 如果除了类型之外，标识符没有其他的语义，而且参数的类型无关紧要。

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

　　要优先使用后缀而不是前缀来表示已有 API 的新版本。

　　考虑使用全新但有意义的标识符，而不是简单地给已有标识符添加后缀或前缀。

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

　　不要在标识符中使用“Ex”（或类似的）后缀来区分相同 API 的不同版本。

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

　　

3.3 程序集和 DLL 的命名

3.4 命名空间的命名

　　要用公司名称作为命名空间的前缀，这样就可以避免与其它公司使用相同的的名字了。

　　要使用稳定的、与版本无关的产品名称作为命名空间的第二层。

　　不要根据公司的组织架构来决定命名空间的层次结构，因为公司内部组织的名称一般经过一段时间后可能会改变。

　　要使用 PascalCasing 大小写风格，并用点号来分隔命名空间的各部分。如果商标使用了非传统的大小写风格，那么即使改风格与常规的大小写风格相悖，也还是应该遵循商标的大小写风格。

　　考虑在适当地时候在命名空间中使用复数形式。

　　不要用相同的名字来命名命名空间以及位于该命名空间的类型。

　　不要引入太一般化的类型名，比如： Element、Node、Log 以及 Message。

　　不要给类型起会与核心命名空间中的任何类型产生冲突的名字。

　　不要给类型起会与同一技术中的其它类型产生冲突的名字。

　　不要在技术命名空间和应用程序模型命名空间的类型之间引入类型名冲突（除非不打算将该技术与该应用程序模型一起使用）。

　　

3.5 类、结构和接口的命名

　　要用名词或名词短语来给类和结构命名。在命名时要使用 PascalCasing 大小写风格。这使类型名和方法区分开，后者采用动词短语来命名。

　　要用形容词短语来给接口命名，在少数情况下也可以使用名词或名词短语。

　　不要给类名加前缀。

　　考虑在派生类的末尾使用基类的名字。

　　要让接口的名字以字母 I 开头，这样可以显示出该类型是一个接口。

　　要确保一对类/接口的名字只相差一个“I”前缀，如果该类是该接口的标准实现。

　　要用描述性的名字来命名泛型类型参数-除非一个字母就可以说明含义就无需使用描述性的名字。

　　考虑用单个字母 T 来命名参数类型 - 如果类型只有一个类型参数并且类型参数只有一个字母。

　　要给描述性的类型参数名加上 T 前缀。

　　考虑在类型参数名中显示出施加于该类型参数上的约束。

　　要遵循描述的规范 - 如果要从 .NET 框架的类型派生新类，或者要实现 .NET 框架中的类型。

　　要用单数名词来命名枚举类型，除非它表示的是位域。

　　要用复数名词来命名表示位域的枚举类型，这样的枚举类型也成为标记枚举。

　　不要给枚举类型的没名字添加“Enum”后缀。

　　不要给枚举类型的名字添加“Flag”或“Flags”后缀。

　　不要给枚举类型值的名字添加前缀。

3.6 类型成员的命名

　　要用名词、名词短语或形容词来命名属性。

　　不要让属性名看起来与“Get”方法的名字相似。

　　要用描述集合中项目短语的复数形式来命名集合属性，而不要使用短语的单数形式加“List”或“Collection”后缀。

　　要用肯定性的短语（CanSeek 而不是 CantSeek）来命名布尔属性。如果有帮助，还可以有选择性地给布尔属性添加“Is”、“Can”或“Has”等前缀。

　　考虑用属性的类型名来命名属性。

　　要用动词或动词短语来命名事件。

　　要用现在时和过去时来赋予事件名之前和之后的概念。

　　不要用“Before”和“After”前缀或后缀来区分前置事件和后置事件。

　　要在命名事件处理函数（用作事件类型的委托）时加上“EventHandler”后缀。

　　要在事件处理函数中用 sender 和 e 作为两个参数的名字。

　　要在命名事件的的参数类时加上“EventArgs”后缀。

　　要在命名字段时使用 PascalCasing 大小写风格。

　　要用名词、名词短语或形容词来命名字段。

　　不要给字段名称加前缀。

3.7 参数的命名

　　要在命名参数时使用 camelCasing 大小写风格。

　　要使用具有描述性的参数名。

　　考虑根据参数的意思而不是参数的类型来命名参数。

　　要使用 left 和 right 来命名重载二元操作符的参数 - 如果参数没有具体的含义。

　　要使用 value 来命名重载一元操作符的参数 - 如果参数没有具体的含义。

　　考虑使用有意义的名字来命名重载操作符的参数 - 如果这样做可以清晰地表达名字的意义。

　　不要在命名重载操作符的参数时，使用缩写或数字编号。

　　

3.8 资源的命名

　　要在命名资源键时使用 PascalCasing 大小写风格。

　　要使标识符的名字具有描述性而不是使名字变短。

　　不要使用各主要 CLR 编程语言特有的关键字。

　　要在命名资源时仅使用字母、数字和下划线。

　　要在命名异常消息的资源时遵循下面的命名约定。

　　

【出处】http://www.cnblogs.com/liqingwen/p/7152673.html