我们应该知道编程规范对于项目的生命周期多么重要,如果每个程序员写的代码都令其他人难以阅读、或者一个团队项目的代码却五花八门,这样的项目将会是怎么样的噩梦。
MS为提供了FXCop工具,用于自动检查代码的规范性、安全性和效率,所以,本文将围绕MS提供的C#.NET代码规范展开。
FXCop工具下载地址:http://www.gotdotnet.com/team/fxcop
1、命名约定
Pascal和Camel命名约定
编程的命名方式主要有Pascal和Camel两种(Pascal:每个单词的首字母大写,例如ProductType;Camel:首个单词的首字母小写,其余单词的首字母大写,例如productType)
标志符
|
规则
|
实例与描述
|
类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;
|
数据成员
|
—
|
以m开头+Pascal命名规则,如mProductType(m意味member)
|
属性
|
Pascal
|
|
1.1、局部变量命名
在primitive的局部变量命名时,使用Camel命名规则,
比如:int type = 0;
double count = 0;
…
对于string类型定义,通常使用str前缀+Pascal命名的方式,
比如string strSQL = string.Empty; 这是一种典型的命名SQL语句字符串的方式
而对于此外的类型对象定义,通常的做法是使用obj前缀+Pascal命名的方式,来告知我们这个变量是一个对象
比如:Application obj Application = new Application();
1.2、参数命名
Camel命名规则,首字母小写
1.3、类数据成员/属性命名
数据成员命名以m开头+Pascal命名方式;
属性以Pascal命名
比如
class EQAppcalition
{
private ArrayList mWorksheetCollection = new ArrayList();
public ArrayList WorksheetCollection
{
get
{
return this.mWorksheetCollection;
}
}
}
另外,类的成员数据/方法调用时,应该加上this限定符,this在编辑环境中是蓝色的,更利于我们区分局部变量、参数或静态变量,并且利于FXCop检测区分。
1.4、命名空间命名
在.之间的限定字符串符合Pascal格式
1.5、委托缩写
委托的命名方式我常常以Pascal命名,或者可以在前面加入On
比如public delegate void OnMouseUp (object sender, MouseEventArgs e);用于处理当Mouse Up时触发的委托
1.6、自定义异常类
我建议自定义异常类以Exception结尾,
比如class EQException: Exception{…} 这是在我的ExcelQuicker控件中异常类的定义方式
1.7、枚举
枚举的命名是Pascal命名
1.8、常量命名
全部大写,单词间并且以下划线间隔,如
public const int LOCK_SECONDS = 3000;
1.9、命名缩写
在一般情况下,我们都不要使用缩写命名,我们从来不害怕长的变量命名,而却担心看不懂的命名。变量命名的原则是,尽最大努力让其他人在看到我们的变量/函数/…等的第一时间,大概能猜出它是做什么的。
比如:int productTypeCount = 0; //我们在第一时间就能知道它是记录产品的数量的变量
而对于糟糕的命名方式:int pTC = 0; //它是productTypeCount的简写,但是其他人或者我们在长时间以后还能知道它是做什么的吗?也许我们不得不查阅相关文档或跟踪代码前后文以明白其意义。
*我们应该认为:最优秀的代码它本身就是注释。我们需要做的,并不在于当时潦草的去实现些什么,而是要让我们的代码具备让他人维护或今后扩充的能力。人需要美,代码也一样。
2、注释规范
2.1、文件头部注释
在代码文件的头部进行注释,标注出创始人、创始时间、修改人、修改时间、代码的功能,这在团队开发中必不可少,它们可以使后来维护/修改的同伴在遇到问题时,在第一时间知道他应该向谁去寻求帮助,并且知道这个文件经历了多少次迭代、经历了多少个程序员的手。
样本:
/********************************************************************************
** 作者: Eunge
** 创始时间:2004-6-8
** 修改人:Koffer
** 修改时间:2004-12-9
** 修改人:Ken
** 修改时间: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、 使用空行,在一段功能代码、或者函数、属性之间插入空行,这样会很直观。
4、界面控件命名
我的建议是使用默认控件名作为前缀,并且首字母小写,符合Camel规范,这样的好处是不必为未知的控件统一命名方式发愁,比如对于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、ADO.NET命名
类型
|
前缀
|
实例
|
Connection
|
con
|
conSQLServer1
|
Command
|
cmd
|
cmdProductType
|
Parameter
|
parm
|
parmProductTypeID
|
DataAdapter
|
dad
|
dadProducts
|
DataReader
|
dr
|
dtrProducts
|
DataSet
|
dst
|
dstProducts
|
DataTable
|
dt
|
dtblCDROM
|
DataRow
|
drow
|
|
DataColumn
|
Dcol
|
…
|
DataView
|
dvw
|
…
|
DataRelation
|
drel
|
…
|
|
|
|
6、代码可读性建议
(1)注意运算符的优先级,我们应该尽量使用括号明确表达式的操作顺序,避免使用默认优先级,给我们以及维护人带来困扰
(2)避免使用不易理解的数字,用有意义的标识来替代(枚举和常量)
比如:
if(productType == 0)
…
else if (productType == 1)
…
(不推荐使用)
|
if(productType == ProductType.CD)
…
else if (productType == ProductType.DVD)
…
(推荐使用)
|
(3)代码中关系较为紧密的代码应尽可能相邻,比如使用objProductType.Name,
而不是objProductType. Name
(4)在界面层中尽量使用异常处理try语句,不要将错误的消息直接暴露给用户,而更应该的是把系统抛出的错误信息记录到LOG日志文件中去,告诉用户友好的提示信息
总结
以上是我写.NET以及编程两年来对规范性的一些总结、体会。如果有疏漏、错误的地方,谢谢大伙的补充、纠正。