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