.NET开发规范
作者： 未知
修改时间： 2017-9-7
版本： 1.0
目录
1..... 概述.......................................................................................................................... 5
2..... 命名规范................................................................................................................... 5
2.1. 类、参数和方法的命名规范......................................................................... 5
2.2. 接口命名规范.............................................................................................. 5
2.3. 动态语言文件命名规则................................................................................ 6
2.3.1. 格式：性质_描述.................................................................................. 6
2.4. 客户端JavaScript规范............................................................................... 6
2.4.1. 变量命名规范....................................................................................... 6
2.4.2. 对象命名规范....................................................................................... 6
2.5. 控件命名规范.............................................................................................. 6
2.6. 图片的命名原则.......................................................................................... 7
2.7. 数据库命名规范.......................................................................................... 8
2.7.1. 命名规范原则....................................................................................... 8
2.7.2. 数据库规范.......................................................................................... 8
2.7.3. 表命名规范.......................................................................................... 8
2.7.4. 字段规范.............................................................................................. 9
2.7.5. 视图规范.............................................................................................. 9
2.7.6. 存储过程规范....................................................................................... 9
2.7.7. 函数规范.............................................................................................. 9
2.7.8. 索引命名规范....................................................................................... 9
2.7.9. 关联命名.............................................................................................. 9
2.7.10. 设计规范............................................................................................. 9
3..... 编码规范................................................................................................................... 9
3.1. C#代码编写................................................................................................ 9
3.2. Request、Session、Application使用规范............................................. 13
3.3. HTML标记语言编码规范.......................................................................... 13
3.4. 注释规范................................................................................................... 13
3.5. 异常规范................................................................................................... 16
- 概述
为了保持应用程序、组件、文件的一致性，便于阅读和管理代码和结构，提高开发效率和产品的标准化，特制订一套开发规范和标准（包括命名规范和编码规范）
命名规范将包括：类和参数的命名规范、接口命名规范、数据库命名规范、ASP命名规范、JavaScript命名规范、控件命名规范等。
编码规范将包括：C#编码规范、注释规范、HTML编码规范、ASP.NET编码规范、异常规范等。
- 命名规范
2.1. 类、参数和方法的命名规范
2.1.1. 用名词或名词短语命名类。
2.1.2. 使用Pascal大写注记：Pascal 大小写形式－所有单词第一个字母大写，其他字母小写。
2.1.3. 不要使用匈牙利命名法。
2.1.4. 用有意义的，描述性的词语来命名变量
- 别用缩写。用name, address, salary等代替 nam, addr, sal 。
- 别使用单个字母的变量象i, n, x 等。使用 index, temp等。用于循环迭代的变量例外。
2.1.5. 文件名要和类名匹配 。
2.1.6. 自定义属性类时，以Attribute作为后缀。
2.1.7. 自定义异常类时，以Exception作为后缀。
2.1.8. 数据表的实体类以Entity作为后缀。
2.1.9. 命名空间引用时，将系统自带的命名空间名放置一起，接着放置自定义的命名空间，最后放置第三方的命名空间。
2.1.10. 所有成员变量应定义在类的前面，并和属性、方法空开一行且只能空开一行。
2.1.11. 当使用Partial类型且每一部分分配一个文件时，主文件以类名命名，后续加入的文件以类名加字母“Ex”加十进制数字序号（如果只有一个扩展类，不需要加数字，超过1个扩展文件，从2开始）命名。
2.1.12. 避免在一个文件中放置多个类。
2.1.13. 避免超过5个参数的方法。使用结构传递多个参数。
2.1.14. 局部变量和方法参数采用camel风格。
2.2. 接口命名规范
使用名词或名词短语，或者描述行为的形容词来命名接口。例如，IComponent（描述性名词），ICustomAttributeProvider（名词短语），和IPersistable（形容词）。使用Pascal大写。
减少接口名中缩写的使用量。不要使用带下划线的字符。在接口名前加前缀I，以表示这个类型是一个接口。不要在类名前加上前缀C。偶而情况下，需要在类名前加上I而并不表示它是一个接口。在这种情况下，只要I后面的字符是小写就可（例如，IdentityStore。）当类是接口的标准执行时，定义这一对类/接口组合就要使用相似的名称。两个名称的不同之处只是接口名前有一个I前缀。
下面我们举个例子，来看看接口IComponent和它的标准执行，类Component。
public interface IComponent {}
public class Component : IComponent {}
public interface IServiceProvider{}
public interface IFormatable {}
2.3. 动态语言文件命名规则
2.3.1. 格式：性质_描述
说明：描述可以有多个单词，用”_”隔开。性质一般是该页面的概要。
范例：register_form.asp，register_post.asp，topic_lock.asp
2.4. 客户端JavaScript规范
2.4.1. 变量命名规范 。
2.4.1.1. 常量以及全局变量名必须全部使用大写字母。
2.4.1.2. 变量名首字母必须小写。
2.4.1.3. 变量名必须使用其类型的所写字符串开始。各种类型的所写字符串如下：
2.4.1.4. 整型变量：int
2.4.1.5. 长整型变量：lng
2.4.1.6. 浮点型变量：flt
2.4.1.7. 双精度变量：dbl
2.4.1.8. 对象引用变量：obj
2.4.1.9. 字符串变量:str
2.4.1.10. Date类型变量：dtm
2.4.1.11. 变量名必须采用有意义的单词命名，如：
2.4.1.12. strUserName、lngArrayIndex
2.4.1.13. 变量名除首字母小写外，其他单词首字符必须大写
2.4.2. 对象命名规范
2.4.2.1. 各种页面对象如text输入框、按钮、下拉选择框在命名时必须使用以下对应前缀：
2.4.2.2. text输入框:txt
2.4.2.3. button按钮：btn
2.4.2.4. select下拉选择框：sel
2.4.2.5. option项:opt
2.4.2.6. form表单：frm
2.4.2.7. frame框架：fra
2.4.2.8. hidden表单项：hdn
2.4.2.9. div标记：div
2.4.2.10. span标记:spn
2.4.2.11. 对话框对象:dlg
2.4.2.12. 窗口对象：wnd
2.4.3. 对JS方法的命名
页面端的JS方法统一写在页面的最下方，以单词或单词短语命名方法。引用JS文件时，注释当前JS文件的作用。
2.5. 控件命名规范
建议是使用控件名简写作为前缀，并且简写的首字母小写，并且整个名字符合Camel规范。
控件命名格式：控件名简写前缀+英文描述。
注意：英文描述中的单词首字母大写。
主要控件名简写对照表：
控件名 | 简写 |
Label | lb |
TextBox | txt |
Button | btn |
CheckBox | chk |
RadioButton | rdo |
CheckBoxList | chklst |
RadioButtonList | rdolst |
ListBox | lst |
DropDownList | ddl |
DataGrid | dg |
DataList | dl |
Image | img |
Table | tbl |
Panel | pnl |
LinkButton | lnkbtn |
ImageButton | imgbtn |
Calender | cld |
AdRotator | ar |
RequiredFieldValidator | rfv |
CompareValidator | cv |
RangeValidator | rv |
RegularExpressionValidator | rev |
ValidatorSummary | vs |
CrystalReportViewer | rptvew |
2.6. 图片的命名原则
2.6.1. 格式：名称分为头尾两部分，用下划线隔开，头部分表示此图片的大类性质，例如广告、标志、菜单、按钮等等 。
2.6.2. 放置在页面顶部的广告、装饰图案等长方形的图片取名： banner
2.6.3. 标志性的图片取名为： logo
2.6.4. 在页面上位置不固定并且带有链接的小图片我们取名为 button
2.6.5. 在页面上位置固定并且不带有链接的背景图片我们取名为 backimg
2.6.6. 在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名： menu
2.6.7. 装饰用的照片我们取名： pic
2.6.8. 不带链接表示标题的图片我们取名： title
2.6.9. 范例：
banner_sohu.gif 、banner_sina.gif、 menu_aboutus.gif 、menu_job.gif、 title_news.gif、 logo_police.gif、 logo_national.gif 、pic_people.jpg 、backimg_notes。
2.7. 数据库命名规范
2.7.1. 命名规范原则
2.7.1.1. 只针对数据库、表、字段、视图、存储过程以及变量的命名规范标准。
2.7.1.2. 旧有的数据表的命名规范不作调整，遵循原有的习惯。
2.7.1.3. 新的数据库设计必须遵循该命名规范。
2.7.1.4. 由于命名规范定义完成比较匆忙，还有很多考虑未周，待以后细节进行补充定义。
2.7.1.5. 对于设计规范需要补充的内容较多，会进一步完善。
2.7.2. 数据库规范
2.7.2.1. 用产品或项目的名字的名词或名词短语命名表；
2.7.2.2. 避免使用特殊字符，如数字，下划线，空格之类；
2.7.2.3. 长度超过20字符可以用简写。
例如：PhysicalExamination（体检）
2.7.2.4. 在数据库中不要定义外键关系。
2.7.2.5. 建立数据库表时，必须建立必要的索引，SQL语句中索引字段不要出现在表达式中,会导致索引失效。
2.7.2.6. 数据库中一定要有表描述以及字段描述。
2.7.2.7. 在同一个数据库中，在事务中更新表的顺序必须严格保持一致，避免死锁的发生。
2.7.2.8. 在同一个事务中，从第一个UPDATE、INSERT、DELETE语句开始，直到Commit或Rollback为止，其中应该全部是UPDATE、INSERT、DELETE语句，尽量减少计算、查询
2.7.2.9. 同一个事务中，语句要尽量少，要力所能及地将大事务拆分为多个小事务。
2.7.3. 表命名规范
2.7.3.1. 使用(项目名称_名词)或(项目名称_名词短语)命名，使用复数而复数只加在最后一个单词上；
2.7.3.2. 避免使用特殊字符，如数字，空格之类；
2.7.3.3. 避免使用拼音缩写（拼音的缩写对阅读造成很大困扰）；
2.7.3.4. 表名称易于理解，准确表达其表功能的英文单词或缩写的英文单词。
2.7.3.5. 如果当前表需要用两个或两个以上的单词来表示，尽量以完整的形式表述。
2.7.3.6. 长度超过20字符可以用简写。
2.7.3.7. 例如：PE_Products（体检产品s），PE_Users（用户s），PE_UserRoles
2.7.3.8. 对于主明细表的，明细表名称为：主表的名称+字符Detail。例如：订单En_Order，其明细为：En_OrderDetail
2.7.3.9. 后台表名尽量与前台表名一致，不区分前后台应用。
2.7.4. 字段规范
2.7.4.1. 采用有意义的字段名，字段名称必须易于理解；
2.7.4.2. 不建议采用”_”的方式进行字段的分段；
2.7.4.3. 避免使用拼音缩写或者特殊字符；
2.7.4.4. 长度超过20字符可以用简写；
2.7.4.5. 命名字段时，不要重复表的名称。例如：Employee表中的字段名不要命名为：EmployeeLastName
2.7.4.6. 不要在字段名称中包括数据类型。
2.7.5. 视图规范
2.7.5.1. 用view_表名等描述视图左右；
例如：view_UserInfo
2.7.5.2. 其它的遵循表的命名规范。
2.7.6. 存储过程规范
2.7.6.1. 前缀加proc_，用动词描述操作类型：
例如：proc_Insert、proc_Update、proc_Delete
2.7.6.2. 其它的遵循表的命名规范。
2.7.7. 函数规范
2.7.7.1. 前缀加func_
2.7.8. 其它的遵循存储过程规范。
2.7.9. 触发器规范
2.7.9.1. 使用"trg_"前缀；
2.7.10. 使用操作类型+表名，如：trg_ProductsInsert
2.7.11. 索引命名规范
2.7.11.1. 索引格式为：IX_+表名+字段名。如：IX_ Employee_Name
2.7.11.2. 如果是主键索引，其格式为：PK_+表名+字段名。如：PK_ Employee_ID
2.7.11.3. 索引命名必须为数据库里唯一
2.7.12. 外键关联命名
2.7.12.1. 关联命名格式为：FK_+表名A+字段名A+表名B+字段名B。如：FK_ Employee_ID_ En_OrderDetail_MainID
2.7.12.2. 外键关联命名基本与索引命名一致。
2.7.13. default
2.7.13.1. 使用格式如：df_{表名}_{列名}
2.7.14. 约束
2.7.14.1. 使用格式如：ck_{表名}_{列名}
2.7.15. 设计规范
2.7.15.1. 数据类型为字符串使用nvarchar，而不用varchar
2.7.15.2. 字段的集合域：CreatorID、Creator、CreatedTime、UpdaterID、Updater、UpdatedTime 关键配置表有必要 如系统参数、机构表等；业务的表（量级大、人为不可操作）可不加 ,如：订单表、日志表等。
2.7.15.3. 明细表建议采用复合主键的方式，而不是单独重新创建一个主键。复合主键注意字段的排列顺序。
2.7.15.4. 如果字段为与其它表相关联为外键，需创建索引。
2.7.15.5. 如果字段为模糊查询之外的条件，需创建索引。
- 3. 编码规范
3.1. C#代码编写
3.1.1. 缩进用 SPACES不用TAB，在VS中设置一个TAB为4个SAPACES（默认设置）。
在VS中通过Ctrl+E, S可以查看目前缩进使用的符号，通过Ctrl+E，D可以格式化文档。
3.1.2. 仅对最需要的类型标记为public，其他的标记为internal
3.1.3. 避免使用?:条件算符。
3.1.4. 编码过程中，如用到单行的测试代码，必须在该测试代码上一行写“//测试代码”，如用到测试代码块，必须用“region 测试代码,endregion”将测试代码块包起来，所有测试代码在Release时必须注释掉。
3.1.5. 避免在布尔条件语句中调用函数。赋值到局部变量并检查它们的值。
3.1.6. 花括弧 ( {} ) 需和括号外的代码对齐。
3.1.7. 在一个类中，各个方法需用一空行，也只能是一行分开。
3.1.8. 花括弧需独立一行，而不象if, for 等可以跟括号在同一行。
好:
不好:
在每个运算符和括号的前后都空一格。
好:
不好:
3.1.9. 避免使用大文件。如果一个文件里的代码超过300～400行，必须考虑将代码分开到不同类中。
3.1.10. 避免写太长的方法。一个典型的方法代码在1～25行之间。如果一个方法发代码超过50行，应该考虑将其分解为不同的方法。
3.1.11. 方法名需能看出它作什么。别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了。
好:
不好:
3.1.12. 一个方法只完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小
好:
不好:
3.1.13. 使用C#的特有类型，而不是System命名空间中定义的别名类型。
好:
不好:
3.1.14. 别在程序中使用固定数值，用常量代替。
3.1.15. 别用字符串常数，用资源文件以便支持多国语言。
3.1.16. 避免使用很多成员变量。声明局部变量，并传递给方法。
3.1.17. 大量需要连接字符串使用StringBuilder替代String。
3.1.18. 不要在方法间共享成员变量。如果在几个方法间共享一个成员变量，那就很难知道是哪个方法在什么时候修改了它的值。
3.1.19. 必要时使用enum 。别用数字或字符串来指示离散值。
好:
不好:
3.1.20. 别把成员变量声明为 public 或 protected,都声明为 private 而使用 public/protected 的Properties。
3.1.21. 不在代码中使用具体的路径和驱动器名。 使用相对路径，并使路径可编程。
3.1.22. 不要在代码中使用硬盘的绝对路径。
3.1.23. 应用程序启动时进行自检以确保所需文件和附件在指定位置，必要时检查数据库链接。
3.1.24. 出现任何问题给用户一个友好和有意义的错误提示。在提示中除了说哪里出现错误之外，还应提示用户如何解决问题。永远别用象"应用程序出错", "发现一个错误" 等错误消息。而应给出象 "更新数据库失败。请确保登陆id和密码正确。" 的具体消息。
3.1.25. 显示错误消息时，除了说哪里错了，还应提示用户如何解决问题。不要用 象 "更新数据库失败。"这样的，要提示用户怎么做："更新数据库失败。请确保登陆id和密码正确。"
3.1.26. 显示给用户的消息简洁而友好，但系统需记录所有可能的信息来帮助诊断问题。
3.1.27. 操作数据库时，如需循环操作，则需进行连接池设定或在事务内一次性提交所有操作。
3.1.28. 查询数据集时，如需对数据集进行筛选后再进行下一步操作，则不能先将筛选前的数据集查询之后再进行内存内的筛选，需在数据库中直接查询出筛选后的结果集。
3.2. Request、Session、Application使用规范
3.2.1. 所有需要放入Session、Application中的对象，必须采用有意义的英文名字。除了被广泛了解的单词缩写以外，不得采用单词缩写。如：
Session(“cp”) = strCurrentUserIP ‘不允许
Session(“CurrentUserIP”) = strCurrentUserIP
Session(“Pwd”) = strPwd ‘允许，Pwd被广泛了解为密码。
3.2.2. 所有需要在代码内用到的Request、Session、Application中的元素，必须在代码头部赋值给代码内声明的变量。
3.2.3. 如果获得Form中提交的内容，必须使用Request.Form(“itemName”).
3.2.4. 如果获得QueryString中提交的内容，必须使用Request.QueryString(“itemName”)
3.2.5. 不得在代码中出现Request(“。。。”)这样的引用方式。
3.3. HTML标记语言编码规范
3.3.1. 标记的换行规范：
一个标记必须占用一行。不得出现两个标记在同一行的情况(同一标记的关闭标记除外)，如：
<tr><td>text</td></tr>
而必须写成：
<tr>
<td>text</td>
</tr>
3.3.2. 标记的关闭规范
3.3.2.1. 静态文件内容必须包含在<body></body>标记中间 。
3.3.2.2. <body>标记必须包含在<html></html>标记中间 。
3.3.2.3. 对于需要关闭的标记，如： <html><title><body><table><tr><td><p><textarea><select><font><option><div><span>
必须同其关闭标记同时出现。如
<body>…<p>…<font>….</font>….</p>…..</body>
3.3.2.4. 不得出现交叉包含的语句，如：
<p><font>…..</p></font>
3.3.2.5. 标记的属性赋值规范
对于接受属性的标记，属性值必须使用双引号或者单引号包围。如:
<body bgcolor=”red”>
<font size=’7’>
注意：必须确保属性的赋值无警告或错误。
3.4. 注释规范
3.4.1. 文件头部注释
在代码文件的头部进行注释，标注出创始人、创始时间、修改人、修改时间、代码的功能，这在团队开发中必不可少，它们可以使后来维护/修改的同伴在遇到问题时，在第一时间知道他应该向谁去寻求帮助，并且知道这个文件经历了多少次迭代、经历了多少个程序员的手。
样本：
/********************************************************************************
** 作者： Eunge
** 创始时间：2004-6-8
** 修改人：Koffer
** 修改时间：2004-12-9
** 修改内容：添加/修改/删除函数X（）
** 修改人：Ken
** 修改时间：2005-01-29
** 修改内容：添加/修改/删除函数Y（）
** 描述：
** 主要用于产品信息的资料录入，…
*********************************************************************************/
我们甚至可以在这段文件头注释中加入版权信息、文件名、版本信息等。
3.4.2. 注释需和代码对齐。类中的方法必须有注释。
好:
不好:
3.4.3. 方法中逻辑判断的地方必须有注释
好:
不好:
3.4.4. 别每行代码，每个声明的变量都做注释，在需要的地方注释。
3.4.5. 如果所有的变量和方法的命名都很有意义，可读性强，则无需太多的注释。
3.4.6. 如果在编码中使用了复杂艰涩的原理，则需为程序配备良好的文档和充分的注释。
3.4.7. 对一个数值变量采用的不是0或-1等数值进行初始化时，应编写注释给出此项赋值的理由。
3.4.8. 对注释做拼写检查，保证语法和标点符号的正确使用。
3.4.9. 避免对显而易见的内容作注释。
3.5. 异常规范
3.5.1. 不要“捕捉了异常却什么也不做”。如果隐藏了一个异常，将永远不知道异常到底发生了没有。
3.5.2. 发生异常时，给出一个友好的信息给用户，但需要精确记录错误的所有可能信息，包括发生时间、方法名称和参数的值、类的名称、使用者的信息等。
3.5.3. 别写太大的try-catch模块，如需要，为每个执行的任务单独编写try-catch模块。
3.5.4. 只捕捉特定的异常，而不是一般的异常。
好：
void ReadFromFile ( string fileName )
{
try { // read from file. }
catch (FileIOException ex) {
// log error. // re-throw exception depending on your case.
throw;
}
}
不好：
void ReadFromFile ( string fileName )
{
try { // read from file. }
catch (Exception ex) {
// Catching general exception is bad.
// was a file error or some other error.
// Here you are hiding an exception.
// In this case no one will ever know that an exception happened.
return "";
}
}
3.5.5. 不必在所有方法中捕捉一般异常。不管它，让程序崩溃。这将帮助你在开发周期发现大多数的错误。
3.5.6. 你可以用应用程序级（线程级）错误处理器处理所有一般的异常。遇到一般性错误时，此错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或用户选择“忽略并继续之前”记录错误信息。
3.5.7. 不必每个方法都用try-catch。当特定的异常可能发生时才使用。比如，当你写文件时，处理异常FileIOException. 。
3.5.8. 如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于IApplicationException。
结尾：
/********************************************************************************
** 作者： 未知
** 创始时间：2004-6-8
** 修改人：12不懂3
** 修改时间：2017-9-97
** 修改内容：更新 版本1.0
*********************************************************************************/