前言
编码规范保证了程序的一致性和统一性，对程序员尤为重要，原因有以下几个：
1、一个软件的生命周期中，80%的花费在于维护。
2、几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护。
3、编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码。每个软件开发人员都必须遵守统一的编码规范。
4、代码尽量简单直白。
命名规范
1、说明
表达清晰的命名规范是程序规划的核心，如果规范的命名能清晰地表达出相应的功能，就可以让人“望文知意”，提高开发效率和系统的可维护性。反之，如果命名不能表达其含义，例如，“aaa”、“bbb()”，那么将事倍功半。
2、Pascal风格
包含一到多个单词，每一个单词第一个字母大写，其余字母均小写。例如：HelloWorld、SetName等。
3、Camel风格
包含一到多个单词，第一个单词首字母小写，其余单词首字母大写。例如：name、productId等。
标识符的大小写规则
（1）除了参数与变量外，所有命名空间名称、类、函数、接口、属性等名称的命名，使用Pascal风格。
（2）参数与变量的命名使用Camel风格。
通用命名规约
约定的是如何选择最适当的名称，这些准则适用于所有标识符的命名。
1、选择名称
（1）请选择易读的英文名称。例如：英文Order的意思为规则、次序、订购等，如果用在排序列中就不是很合适，用来表示订单则更具可读性。可读性比详细描述更重要，比如表示坐标名称的ScreenX就比ScreenHorizontally更具可读性。
（2）除下划线外，不要使用连字符或任何其他非字母数字字符。在数据库表字段名称设计时，与其他表字段有关联时，适当地使用表名+下划线+字段名，可以更清晰地表现出该字段与关联表对应字段的关系。比如产品分类表ProductClass中有字段Id和Name，那么产品表绑定的这两个字段可命名为ProductClass_Id与ProductClass_Name，这样在查看产品表时就可以清晰地知道这两个字段与分类表的关系。
（3）避免使用与常用编程语言的关键字冲突的标识符。
（4）变量和方法参数使用Camel风格。例如：
string productName="";
int number=0;
string sqlString="";
double averageScore=0.0;
Users users=new Users();
Users model=new Users();
Users userModel=new Users();
const string const_String="";
private string GetProductName(int id)
{
return "";
} （5）不要使用成员属性作为成员变量的前缀（其他变量命名也一样）。例如：不要像Users m_users;这样定义成员变量，可以使用第（4）点的设置。
2、字母缩写词
（1）通常不要使用缩写。
（2）除非这种缩写已被广泛接受，或者团队当中大家都认可这种缩写。例如：使用OnButtonClick，如果团队中普遍认可OnBtnClick这种写法也是可以的。
命名空间命名
命名空间的命名采用Pascal风格，取名的一般规则为Jujianfei.ProjectName(人名.项目名称)，例如：Jujianfei.SetName；需要用复数时，请使用复数，例如：使用System.Collections而不是System.Collection；需要缩写时，不需要加复数，例如：使用System.IO而不是System.IOs。
类、结构和接口命名
（1）按照Pascal大小写格式，使用名词或名词短语为类、接口和值类型命名。
（2）接口命名以字母I为前缀，例如：Icomponent。
（3）派生类的末尾使用基类名称。例如：从Stream继承的类型以Stream结尾，从Exception继承的类型以Exception结尾。
逻辑层类命名
按照Pascal大小写格式，使用名词或名词短语命名，并加上后缀Logic。
文件夹命名
文件夹以功能模块名称，按照Pascal大小写格式命名。比如后端管理功能及权限相关功能，全部放到System文件夹里。
代码编码规范
（1）缩进和间隔。缩进使用Tab键，不用Spaces键。
（2）注释需和代码对齐。多使用#region和#endregion代码块。
（3）在代码中垂直对齐左括号和右括号。
if（x==0）
{
Response.Write("");
}不要出现以下情况。
if（X==0）{
Response.Write("");
}或者：
if（x==0）{ Response.Write(""); } （4）适当地增加空行，来增加代码的可读性。
在下列情况下应该有两行空行：
①同一文件的不用部分之间。
②在类、接口及彼此之间。
在下列情况下应该有一行空行：
①方法之间。
②局部变量和它后边的语句之间。
③方法内的功能逻辑部分之间。
（5）避免使用大文件。如果一个文件里的代码超过300行，必须考虑将代码分开到不同的类中。当然，模板生成类与逻辑层类除外。
（6）避免写太长的方法。一个典型的方法代码在1-25行之间。如果一个方法代码超过25行，应该考虑将其分解为不同的方法。
（7）为了防止在阅读代码时不得不滚动源代码编辑器，每行代码或注释在1024×768的显示频率下不得超过一显示屏。
（8）在大多数运算符之前和之后使用空格，这样做不会改变代码的意图，却可以使代码容易阅读。。例如：
int j = i + k;而不应该写：
int j=i+k；括号和它里面的字符之间不应该出现空格，括号应该和它前面的关键词留有空格。例如：
while (true)
{
}但是方法名和左括号之间不应该有空格。例如：
method(int i1, int i2)for语句里的表达式之间加空格。例如：
for(int i = 0; i < 10; i++)强制类型转换时，在类型和变量之间加一个空格。例如：
(int) i; （9）所有可供用户输入的字段值，必须忽略前后空白（不包含密码）；在对字段值进行有效性验证时，对提交进数据库的内容必须进行SQL注入过滤与XSS过滤。
（10）一个方法只能完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小。
（11）避免使用很多成员变量，声明局部变量，并传递给方法。
（12）不要在方法间共享成员变量，如果在几个方法间共享一个成员变量，那就很难知道是哪个方法在什么时候修改了它的值。
（13）不在代码中使用具体的路径和驱动器名，使用相对路径，并使路径可编程。永远别设想你的代码是在“C:”盘运行。你不会知道，一些用户在网络或“Z:”盘运行程序。
（14）应用程序启动时进行“自检”并确保所需文件和附件在指定的位置。如果需要的配置文件找不到，应用程序需自己创建使用默认值的一份。如果在配置文件中发现错误值，应用程序要抛出错误，给出提示消息告诉用户正确值。
（15）出现任何问题给用户一个友好的提示，错误消息需能帮助用户解决问题。永远别用像“应用程序出错”、“发现一个错误”等之类的错误消息，而应给出像“更新数据库失败，请确保登录ID和密码正确”的具体消息。显示错误消息时，除了说哪里错了，还应提示用户如果解决问题。
（16）错误处理和异常事件
不要“捕捉了异常却什么也不做”。如果隐藏了一个异常，你将永远不知道异常到底发生了没有。发生异常时，给用户提示友好的消息，但要精确记录错误的所有可能细节，包括发生的时间和相关方法、类名等。别写太大的try-catch模块。如果需要，为每个执行的任务编写单独的try-catch模块。这将很容易找出哪一段代码产生异常，并给用户发出特定的错误消息。如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于.IApplicationException。