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