C#的命名规范 2

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;
数据成员                      Camel                     以m开头＋Pascal命名规则，如mProductType（m意味member）
属性                            Pascal

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

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

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

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

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

样本：

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

** 作者： Eunge

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

** 修改人：Lucy

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

** 修改人：Lucy

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

** 描述：

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

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

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

例如：

/// <summary>

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

/// </summary>

class ProductTypeCollector

{

       …

}

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

界面控件命名
我的建议是使用默认控件名作为前缀，前缀名称全部小写，这样的好处是不必为未知的控件统一命名方式发愁，比如对于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;

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

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