.NET命名规范约定参考大全

一组一致的的命名约定对框架的可用性及其重要。 名字要易于理解,同时必须传达每个元素的功能。

.NET命名规范之大小写约定

标识符的大小写规则

◆PascalCasing:如HtmlTag  IOStream

◆camelCasing:如htmlTag  ioStream

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

◆要把camelCasing用于参数的名字。

.NET命名规范之通用命名约定

单词的选择

对框架中标识符的名字来说,很重要的一点是一目了然。

名字的意思清楚比长度短更重要。名字应该与场景、系统的逻辑组成或物理组成以及为人熟知的概念相对应,而不应该与技术或框架相对应。

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

◆要更看重可读性,而不是更看重简短性;

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

◆不要使用匈牙利命名法;

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

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

一般来说,不要在标识符中使用单词缩写或首字母缩写:宁可名字长一点,也不要别人看不懂。  尤其不要使用未被广泛接受的单词缩写和首字母缩写词。

◆不要使用缩写词或缩略词作为标识符名字的一部分

◆用GetWindow  不用GetWin

◆不要使用未被广泛接受的首字母缩写词

何谓广泛接受:用搜索引擎在网上搜索该首字母缩写词,如果返回的前几个结果与期望相符,那么该首字母缩写词才有资格被称为众所周知。

◆避免使用语言特有的名字

◆要给类型名使用语义上有意义的名字,而不要使用特有的关键字

◆GetLength比GetInt要好

◆要使用CLR的通用类型名,而不要使用语言特有的别名

◆要使用常见的名字,比如value或item,而不要重复类型的名字

为已有API的新版本命名

当用新类型和新成员接替或取代已有的类型或成员时,如何选择名字:

◆使用与旧API相似的名字

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

这样有助于在浏览文档或使用Intellisense时发现新版本:按字母排序

◆可以考虑使用全新但有意义的标识符

◆要使用数字后缀来表示已有API的新版本

◆有些名字(或工业标准)不宜添加后缀或改名

◆不要在标识符中使用“Ex”“New”等类似的后缀来区分相同API的不同版本

◆要在引入64位整数(long)而非32位整数进行操作的新版本API时使用“64”后缀,反之亦然。

.NET命名规范之程序集和DLL的命名

程序集是一个部署单元,同时还代表托管代码程序的身份。虽然程序集可以分布一个或多个文件中,但一般来说一个程序集仅与一个DLL相对应。

名字空间与DLL程序集的区别:

◆名字空间:一组逻辑实体

◆DLL和程序集:打包和部署时的一个单

◆要为程序集和DLL选择提示性的名字,比如System.Data,这样很容易就知道它的大致功能。

◆DLL命名:< Company>.< Component>.dll

.NET命名规范之名字空间的命名

< Company>.(< Product>|< Technology>)[.< Feature>][.< Subnamespace>]

◆要用公司名称作为名字空间的前缀,不要用缩写

◆要用稳定的与版本无关的产品名称作为名字空间的第二层

◆不要根据公司的组织架构来决定名字空间的层次结构,因为公司内部组织的名称一般来说不会持续太长的时间

◆要使用PascalCasing大小写风格,并用点号来分隔名字空间的各部分。

如Microsoft.Office.PowerPoint

◆考虑适当的时候在名字空间中使用复数形式。  首字母缩写词例外

System.Collections

System.IO

◆不要用相同的名字来命名名字空间与位于该名字空间中的类型

如:不要将名字空间命名为Debug,然后又在该名字空间中提供一个名为Debug的类。

名字空间和类型冲突

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

◆不同类型的名字空间,有不同的规范来避免类型名的冲突:

应用程序模型名字空间(application model namespace)

属于单个应用程序模型的名字空间经常一起使用,但是它们几乎不合属于其他应用程序模型的名字空间一起使用

System.Windows*

System.UI*

基础设施名字空间(infrastructure namespace)

此类别包含一些在开发常用应用程序时很少会导入的名字空间

核心名字空间(core namespace)

包含了所有的System名字空间,但应用程序模块名字空间和基础设施名字空间除外。  包括System、System.IO、System.Xml以及System.Net等等

技术名字空间组(technology namespace group)

此类别包含所有那些以相同的两个前缀(< Company>.< Technology>*)开始的名字空间。

.NET命名规范之类、结构和接口的命名

一般来说类型名应该是名词词组。如果无法为类型找到一个名词词组,那么应该重新考虑类型的总体设计。

另一个中重要的考虑因素:最易于识别的名字应该用于最常用的类型。

最常用的类型名应该反映出使用场景,而不是继承层次。

要用名词词组来给类型命名。使用PascalCasing风格

不要给类名加前缀

只有接口才能(可以)被加前缀“I”,那是因为.NET框架受到COM及Java的影响

考虑让派生类的名字以其基类结尾

public class FileStream : Stream {...}

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

public interface IComponent {...}

public class Component : IComponent {...}

泛型类型参数的命名

要用描述性的名字来命名

考虑用T来命名参数类型

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

考虑在类型参数中显示出施加于该类型参数上的限制

枚举类型的命名

要用单数名词来命名枚举类型,除非它表示的是位域(bit field)

不要给枚举类型的名字添加“Enum”后缀,也不要添加“Flag”、“Flags”等后缀

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

此规范与C++中通常所使用的恰好相反。在C++中给枚举的每个成员加上完成的限定符是很重要的,因为它们可能在枚举名的作用域之外被访问。但是在托管代码中,枚举成员只能通过枚举名的作用域来访问。

.NET命名规范之类型成员的命名

类型:方法、属性、事件、构造函数、字段

方法的命名

要尽量根据方法所对应的任务来给它们命名,而不要根据一些实现细节。

要用动词或动词词组来命名方法

属性的命名

要用名词、名词词组或形容词来命名属性

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

要用肯定性的短语(CanSeek而不是CantSeek)来命名布尔属性

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

 
 
 
  1. public enum Color {...}  
  2.  
  3. public class Control  
  4. {  
  5. public Color Color  
  6. {  
  7. get {...}  
  8. set {...}  
  9. }  
  10. }   

事件的命名

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

事件总是表示一些动作,要么正在发生,要么已经发生

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

窗口关闭之前发生的close事件:Closing

窗口关闭之后发生的close时间:Closed

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

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

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

sender:触发事件的对象,在整个.NET框架中,sender为object类型

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

字段的命名

PascalCasing风格

名词或名词短语

不要给字段名添加前缀

.NET命名规范之参数的命名

camelCasing风格

要使用描述性的参数名

参数名要具备足够的描述性,使得在大多数情况下,用户根据参数的名字和类型就能够确定它的意思

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

.NET命名规范之资源的命名

本地化的资源就好比是属性,可以通过特定的对象来引用。因此,它的命名规范与属性的相似。

要在命名属性关键字(resource key)时使用PascalCasing大小写风格

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

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

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

要用点号来给标识符清楚地划分层次

要在为异常消息资源命名是遵循下面的命名约定:

资源标识符应该是异常的类型名加一个简短的异常标识符,之间以点号分隔

【编辑推荐】

  1. 详细介绍C#命名规范
  2. ASP.NET编程规范之命名规范浅析
  3. 浅析C#命名规范和Camel命名法
  4. C++、Java与C#的命名规范总结
  5. C#结构体的特点浅析
THE END