C#命名规范--.NET编程

1、命名约定

Pascal和Camel命名约定

编程的命名方式主要有Pascal和Camel两种（Pascal：每个单词的首字母大写，例如ProductType；Camel：首个单词的首字母小写，其余单词的首字母大写，例如productType）

以下是一些常用的C#成员及其推荐命名方法： 

标志符	规则	实例与描述
类class	Pascal	Application
枚举类型enum	Pascal	记住，是以Pascal命名，切勿包含Enum，否则FXCop会抛出Issue
委托delegate	Pascal	以Pascal命名，不以任何特殊字符串区别于类名、函数名
常量const	全部大写	全部大写，单词间以下划线隔开
接口interface	Pascal	IDisposable 注：总是以 I 前缀开始，后接Pascal命名
方法function	Pascal	ToString
命名空间namespace	Pascal	以.分隔，当每一个限定词均为Pascal命名方式，比如： using ExcelQuicker.Framework
参数	Camel	首字母小写
局部变量	Camel	也可以加入类型标识符，比如对于System.String类型，声明变量是以str开头，string strSQL = string.Empty;
数据成员	Camel	以m开头＋Pascal命名规则，如mProductType（m意味member）
属性	Pascal

 

1.1、局部变量命名

在primitive的局部变量命名时，使用Camel命名规则，

比如：int type = 0;

double count = 0;

…

对于string类型定义，通常使用str前缀＋Pascal命名的方式，

比如string strSql = ""; //这是一种典型的命名SQL语句字符串的方式。

而对于此外的类型对象定义，通常的做法是使用obj前缀＋Pascal命名的方式，来告知我们这个变量是一个对象。或者也可以直接使用类名的Camel命名规则。

比如：Application objApplication = new Application();

            Application application = new Application();

 

1.2、参数命名

Camel命名规则，首字母小写

 

1.3、类数据成员/属性命名

数据成员命名以Camel命名方式，而属性以Pascal命名。通常如果数据成员与属性成对的话，数据成员与属性的命名区别仅在于变量名的第一个字母是小写还是大写。

比如

class Appcalition

{

        private ArrayList worksheetCollection = new ArrayList();

        public ArrayList WorksheetCollection

        {

            get

            {

                return this.worksheetCollection;

            }

        }

}

另外，类的成员数据/方法调用时，应该加上this限定符，this在编辑环境中是蓝色的，更利于我们区分局部变量、参数或静态变量，并且利于FXCop检测区分。（如果使用FxCop扫描和检测代码的话）

 

1.4、命名空间命名

在dot之间的各限定字符串符合Pascal格式

 

1.5、委托缩写

委托的命名方式我常常以Pascal命名，并且在命名的后面加EventHandler

比如public delegate void MouseEventHandler (object sender, MouseEventArgs e);    //用于处理与鼠标相关的事件或委托

对于自定义的委托，其参数第一个建议仍然使用object sender，sender代表触发这个时间或委托的源对象。而第二个参数继承于EventArgs类，并且在派生类中实现自己的业务逻辑。

 

1.6、自定义异常类

自定义异常类以Exception结尾，并且在类名中能清楚的描述出该异常的原因。比如NotFoundFileException，描述出了某个实体（文件、内存区域等）无法被找到。

1.7、枚举

枚举的命名是Pascal命名，不需要在枚举中加入Enum，枚举的名称能清楚的表明该枚举的用途。

 

1.8、常量命名

全部大写，单词间并且以下划线间隔，如public const int LOCK_SECONDS = 3000;  虽然在MSDN中常量的命名推荐使用Pascal，但是从C++沿袭的命名规则来看，将常量全部大写更加能清楚的表示常量与普通变量之间的区别。

 

1.9、命名缩写

在一般情况下，不推荐缩写命名，不要担心变量命名长，长的变量名能使变量的意义更加清晰，其实从长变量名的负面作用三，因为Ctrl+C和Ctrl+V加上在VS中的智能感知，其负面追用已经很小。变量命名的原则是，尽最大努力让其他人在看到我们的变量/函数/…等的第一时间，大概能猜出它是做什么的。

比如：int productTypeCount = 0; //我们在第一时间就能知道它是记录产品的数量的变量

而对于糟糕的命名方式：int prodTypeCount = 0; //它是productTypeCount的简写，我们一部分人也许知道prod是product的缩写，但是每人能保证所有的人都知道它。我个人认为：最优秀的代码它本身就是注释。作为一流的程序员。并不仅仅实现功能，而是要让我们的代码更加优美，具备让他人维护或今后扩充的能力。作为现在的业务系统，其门槛的准入水平已大大降低，实现功能上的需求已没有什么难度，但是高手和菜鸟的区别在于，高手的代码通俗易懂，在整个编码的过程中，不仅能考虑到性能、还会考虑代码可读性和维护性。

1.10、数据库命名

数据库的字段、表名的命名都推荐采用Pascal命名方式，尽量不采用缩写。当然，使用长的字段名、表名，可能会使SQL语句的编写带来负面影响。我推荐大家可以使用一些ORM，ORM的性能肯定不会比直接写SQL的好，但是如果做业务系统，更重要的是系统多久能交付用户使用，ORM不仅使开发时间可以缩短不少，并且在后期的维护上也比直接写SQL便利很多。

2、注释规范

2.1、文件头部注释

在代码文件的头部进行注释，这样做的好处在于，我们能对代码文件做变更跟踪。在代码头部分标注出创始人、创始时间、修改人、修改时间、代码的功能，这在团队开发中必不可少，它们可以使后来维护/修改的同伴在遇到问题时，在第一时间知道他应该向谁去寻求帮助，并且知道这个文件经历了多少次迭代、经历了多少个程序员的开发和修改。

样本：

/********************************************************************************

** 作者： Eunge

** 创始时间： 2004-6-8

** 修改人：Lucy

** 修改时间：2004-12-9

** 修改人：Lucy

** 修改时间：2005-01-29

** 描述：

**    主要用于产品信息的资料录入，…

*********************************************************************************/

 

2.2、函数、属性、类等注释

请使用///三斜线注释，这种注释是基于XML的，不仅能导出XML制作帮助文档，而且在各个函数、属性、类等的使用中，编辑环境会自动带出注释，方便你的开发。以protected，protected Internal，public声明的定义注释都建议以这样命名方法。

例如：

/// <summary>

/// 用于从ERP系统中捞出产品信息的类

/// </summary>

class ProductTypeCollector

{

       …

}

 

2.3、逻辑点注释

在我们认为逻辑性较强的地方加入注释，说明这段程序的逻辑是怎样的，以方便我们自己后来的理解以及其他人的理解，并且这样还可以在一定程度上排除BUG。在注释中写明我们的逻辑思想，对照程序，判断程序是否符合我们的初衷，如果不是，则我们应该仔细思考耀修改的是注释还是程序了…

 

3、排版

我的排版原则与建议：

1、  每行语句至少占一行，如果语句过长（超过一屏），则该语句断为两行显示；

2、  把相似的内容放在一起，比如数据成员、属性、方法、事件等，并适当的使用#region…#endregion，我最喜欢把机器生成的代码都放在一个#region里面，比如在编写ASP.NET程序时，对应自动产生的控件定义，我常用#region Automatic Generated Web Components … #endregion把他们框住

3、  使用空格，

（1）       双目操作符的前后加空格(+, =, && 等)，index = index + 1;

（2）       单目操作符前加空格(!, ++, ~ 等)， index ++;

（3）       逗号、分号只在后面加空格

4、  使用空行，在一段功能代码、或者函数、属性之间插入空行，这样会很直观。

在Visual Studio 2005中，其实已经带有代码格式化这样的功能，快捷键是Ctrl+K -> Ctrl+D。

 

4、界面控件命名

我的建议是使用默认控件名作为前缀，前缀名称全部小写，这样的好处是不必为未知的控件统一命名方式发愁，比如对于Label标签控件，有的人用缩写lbl，有的人用lab，有的人用lb。这样其实仍然是避免使用缩写，有的时候仍然会使命名变得冗长，但是命名更加能反应出变量的意义，并且各个开发人员也能更好的执行，因为他们不需要去背记各个变量的缩写。

protected System.Web.UI.WebControls.Button buttonQuery;

protected System.Web.UI.WebControls.DropDownList dropdownlistProductType;

protected System.Web.UI.WebControls.TextBox textboxManufactureDate;

 

5、代码可读性一些建议

（1）注意运算符的优先级，我们应该尽量使用括号明确表达式的操作顺序，避免使用默认优先级，给我们以及维护人带来困扰

（2）避免使用不易理解的数字，用有意义的标识来替代（枚举和常量）

比如：

if(productType == 0)        … else if (productType == 1)        … （不推荐使用）

if(productType == ProductType.CD)        … else if (productType == ProductType.DVD)        … （推荐使用）

 

（3）在界面层中尽量使用异常处理try语句，不要将系统级别的错误直接暴露给用户，而更应该的是把系统抛出的错误信息记录到LOG日志文件中去，告诉用户友好的提示信息

在Visual Studio 2005里面，有代码布局格式化功能，蛮有用的。其实代码的规范是为了使系统具有整体一致的编码风格，以使后期维护人员能更快的读懂代码并进行维护。我认为代码规范有其必要性，但不能因为规范而规范，从开发而言，开发是为了更快的做出稳定的系统，而稳定的系统是为了给公司带来受益。开发人员、项目管理人员都应该更多的从项目经营的角度出来，同时站在公司、客户的角度考虑问题，而不是因为代码而代码。

作为使用Microsoft东西的，多少还是要先顾及一下Microsoft的忠告：

微软的命名警告：
1.避免在参数中使用特定于语言的类型名

2.避免在参数中使用类型名

3.不要将枚举值命名为“Reserved”

4.不要将类型名用作枚举值的前缀

5.事件不应具有 before 或 after 前缀

6.标识符的大小写应该正确

7.标识符不应仅以大小写进行区分

8.标识符应具有正确的前缀

9.标识符应具有正确的后缀

10.标识符不应包含下划线

11.标识符应采用正确的前缀

12.标识符应采用正确的后缀

13.标识符不应与关键字冲突

14.较长的首字母缩略词应采用 Pascal 大小写格式

15.参数名应与基方法中的声明保持一致

16.参数名不应与成员名冲突

17.属性名不应与 get 方法冲突

18.较短的首字母缩略词应全部大写

19.类型名不应与命名空间冲突

20.使用首选词条

下面是我常用的一些控件缩写，还有一些，我会慢慢加进来的。

控件类型	建议缩写
Button	btn
Check box	chk
DropDownList	ddl
Combobox	cmb
Data grid	dgd
Data repeater	rpt
Form	frm
IFrame	ifr
Image	img
Label	lbl
List box	lst
Picture box	pic
ProgressBar	prg
RadioButton	rbt
Text box	txt
TreeView	trv

还有一些数据类型的缩写：

数据类型	数据类型简写
Array	ary
Boolean	bln
Byte	byt
Char	chr
DateTime	dtm
Decimal	dcm
Double	dbl
Integer	int
Long	lng
Object	obj
Single	sng
String	str

几年以前,Charles Simonyi(他后来成为微软的著名程序员)设计了一种以前缀为基础的命名方法,这种方法后来称为"匈牙利表示法"以记念他.他的思想是根据每个标识符所代表的含义给它一个前缀.微软后来采用了这个思想,给每个标识符一个前缀以说明它的数据类型.因此,整型变量的前缀是n,长整型变量是nl,字符型数组变量是ca,以及字符串(以空类型结尾的字符数组)以sz为前缀.这些名字可能会非常古怪.比如说:lpszFoo表示"Foo"是一个指向以空字符为结尾的字符串的长整型指针.

这种方法的优点是使人能够通过变量的名字来辨别变量的类型,而不比去查找它的定义.遗憾的是,这种方法不仅使变量名字非常绕口,而且使改变变量类型的工作变得十分艰巨.在Windows3.1中,整型变量为16为宽.如果我们在开始时采用了一个整型变量,但是在通过30---40个函数的计算之后,发现采用整型变量宽度不够,这时我们不仅要改变这个变量的类型,而且要改变这个变量在这30--40个函数中的名字.

因为不切实际,到现在已经很少有人再使用"匈牙利表示法"了.毫无疑问,在某种场合它依然存在,但大部分人现在已经抛弃它了.一般而言,输入前缀是一种糟糕的想法,因为它把变量于其类型紧紧地绑在了一起.

所以使用类型前缀还是需要慎重考虑。