文档介绍：C#.NET编程规范
——修订版
（请使用 Office 2003 来阅读本文档，以获得最佳效果）
我们应该知道规范对于系统的生命周期多么重要，试想如果每个程序员写的程序其他人都难以阅读，最后只能由他本人去维护、修改的话，软件开发方式
、命名缩写
在一般情况下，我们都不要使用缩写命名，我们从来不害怕长的变量命名，而却担心看不懂的命名。变量命名的原则是，尽最大努力让其他人在看到我们的变量/函数/…等的第一时间，大概能猜出它是做什么的。
比如：int productTypeCount = 0; //我们在第一时间就能知道它是记录产品的数量的变量
而对于糟糕的命名方式：int pTC = 0; //它是productTypeCount的简写，但是其他人或者我们在长时间以后还能知道它是做什么的吗？也许我们不得不查阅相关文档或跟踪代码前后文以明白其意义。
*我们应该记住：最优秀的代码它本身就是注释。我们需要做的，并不在于当时潦草的去实现些什么，而是要让我们的代码具备让他人维护或今后扩充的能力。人需要美，代码也一样。
2、注释规范
、文件头部注释
在代码文件的头部进行注释，标注出创始人、创始时间、修改人、修改时间、代码的功能，这在团队开发中必不可少，它们可以使后来维护/修改的同伴在遇到问题时，在第一时间知道他应该向谁去寻求帮助，并且知道这个文件经历了多少次迭代、经历了多少个程序员的手。
样本：
我们甚至可以在这段文件头注释中加入版权信息、文件名、版本信息等。
、函数、属性、类等注释
请使用///三斜线注释，这种注释是基于XML的，不仅能导出XML制作帮助文档，而且在各个函数、属性、类等的使用中，编辑环境会自动带出注释，方便你的开发。以protected，protected Internal，public声明的定义注释请都以这样命名方法。
例如：
/// <summary>
/// 用于从ERP系统中捞出产品信息的类
/// </summary>
class ProductTypeCollector
{
…
}
、逻辑点注释
在我们认为逻辑性较强的地方加入注释，说明这段程序的逻辑是怎样的，以方便我们自己后来的理解以及其他人的理解，并且这样还可以在一定程度上排除BUG。在注释中写明我们的逻辑思想，对照程序，判断程序是否符合我们的初衷，如果不是，则我们应该仔细思考耀修改的是注释还是程序了…
3、排版
我的排版原则与建议：
每行语句至少占一行，如果语句过长（超过一屏），则该语句断为两行显示；
把相似的内容放在一起，比如数据成员、属性、方法、事件等，并适当的使用#region…#endregion，我最喜欢把机器生成的代码都放在一个#region里面，，对应自动产生的控件定义，我常用#regionAutomatic Generated Web Components… #endregion把他们框住
使用空格，
目操作符的前后加空格(+, =, && 等)
单目操作符前后不加空格(!, ++, ~ 等)
逗号、分号只在后面加空格
使用空行，在一段功能代码、或者函数、属性之间插入空行，这样会很直观。
4、界面控件命名
我的建