.NET开发规范VIP

.NET开发规范编写： 审核： 批准： 目录1.概述52.命名规范52.1.类、参数和方法的命名规范52.2.接口命名规范52.3.动态语言文件命名规则62.3.1.格式：性质_描述62.4.客户端JavaScript规范62.4.1.变量命名规范62.4.2.对象命名规范62.5.控件命名规范62.6.图片的命名原则72.7.数据库命名规范82.7.1.命名规范原则82.7.2.数据库规范82.7.3.表命名规范82.7.4.字段规范92.7.5.视图规范92.7.6.存储过程规范92.7.7.函数规范92.7.8.索引命名规范92.7.9.关联命名92.7.10.设计规范93.编码规范93.1.C#代码编写93.2.Request、Session、Application使用规范133.3.HTML标记语言编码规范133.4.注释规范133.5.异常规范16 1. 概述为了保持应用程序、组件、文件的一致性，便于阅读和管理代码和结构，提高开发效率和产品的标准化，特制订一套开发规范和标准（包括命名规范和编码规范）。命名规范将包括：类和参数的命名规范、接口命名规范、数据库命名规范、ASP命名规范、JavaScript命名规范、控件命名规范等。编码规范将包括：C#编码规范、注释规范、HTML编码规范、ASP.NET编码规范、异常规范等。2. 命名规范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 IServiceProviderpublic interface IFormatable 2.3. 动态语言文件命名规则2.3.1. 格式：性质_描述说明：描述可以有多个单词，用”_”隔开。性质一般是该页面的概要。范例：register_form.asp，register_post.asp，topic_lock.asp2.4. 客户端JavaScript规范 2.4.1. 变量命名规范 . 常量以及全局变量名必须全部使用大写字母. 变量名首字母必须小写. 变量名必须使用其类型的所写字符串开始。各种类型的所写字符串如下： . 整型变量：int . 长整型变量：lng . 浮点型变量：flt . 双精度变量：dbl . 对象引用变量：obj . 字符串变量:str 0. Date类型变量：dtm 1. 变量名必须采用有意义的单词命名，如： 2. strUserName、lngArrayIndex 3. 变量名除首字母小写外，其他单词首字符必须大写 2.4.2. 对象命名规范 . 各种页面对象如text输入框、按钮、下拉选择框在命名时必须使用以下对应前缀： . text输入框:txt . button按钮：btn . select下拉选择框：sel . option项:opt . form表单：frm . frame框架：fra . hidden表单项：hdn . div标记：div 0. span标记:spn 1. 对话框对象:dlg 2. 窗口对象：wnd 2.5. 控件命名规范建议是使用控件名简写作为前缀，并且简写的首字母小写，并且整个名字符合Camel规范。控件命名格式：控件名简写前缀+英文描述注意：英文描述中的单词首字母大写主要控件名简写对照表控件名简写LabellblTextBoxtxtButtonbtnCheckBoxchkRadioButtonrdoCheckBoxListchklstRadioButtonListrdolstListBoxlstDropDownListddlDataGriddgDataListdlImageimgTabletblPanelpnlLinkButtonlnkbtnImageButtonimgbtnCalendercldAdRotatorarRequiredFieldValidatorrfvCompareValidatorcvRangeValidatorrvRegularExpressionValidatorrevValidatorSummaryvsCrystalReportViewerrptvew2.6. 图片的命名原则2.6.1. 格式：名称分为头尾两部分，用下划线隔开，头部分表示此图片的大类性质，例如广告、标志、菜单、按钮等等 。 2.6.2. 放置在页面顶部的广告、装饰图案等长方形的图片取名： banner 2.6.3. 标志性的图片取名为： logo2.6.4. 在页面上位置不固定并且带有链接的小图片我们取名为 button 2.6.5. 在页面上位置固定并且不带有链接的背景图片我们取名为 backimg2.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.2. 数据库规范. 数据库命名以公司名称Sunivo+应用程序名称的英文单词或缩写组合. 应用程序名称单词第一个字母要大写，如：SunivoSupplyCashBalance, SunivoSupCash2.7.3. 表命名规范. 表名称易于理解，准确表达其表功能的英文单词或缩写的英文单词. 如果当前表需要用两个或两个以上的单词来表示，尽量以完整的形式表述，如太长可采用两个单词的缩写形式例如：客户物料表，Sys_CustItem. 按模块功能分类，标识前缀模块名称前缀公用Pub公用的系统块Pub_Sys公用的日志块Pub_Log核心产品Core字典DD英文前台En中文前台Cn供应商ProviderReachReach人事管理Hr现金流Cash基础Bas销售Sunivo改为Sale采购Sunivo改为：Stock物流Wl财务Sunivo改为：Finance报表Rpt其它Oth. 命名表时，用单数形式表示。例如：Employee，而不使用Employees. 对于主明细表的，明细表名称为：主表的名称+字符Detail。例如：订单En_Order，其明细为：En_OrderDetail. 后台表名尽量与前台表名一致，不区分前后台应用。2.7.4. 字段规范. 采用有意义的字段名，字段名称必须易于理解. 不建议采用”_”的方式进行字段的分段. 主键的内码字段，统一标识，取为：ID，采用整型或长整型. 命名字段时，不要重复表的名称。例如：Employee表中的字段名不要命名为，EmployeeLastName. 不要在字段名称中包括数据类型。2.7.5. 视图规范. 前缀加VW. 其它的遵循表的命名规范2.7.6. 存储过程规范. 前缀加UP. 其它的遵循表的命名规范2.7.7. 函数规范. 前缀加UF. 其它的遵循表的命名规范2.7.8. 索引命名规范. 索引格式为：IX_+表名+字段名。如：IX_ Employee_Name. 如果是主键索引，其格式为：PK_+表名+字段名。如：PK_ Employee_ID. 索引命名必须为数据库里唯一2.7.9. 关联命名. 关联命名格式为：FK_+表名A+字段名A+表名B+字段名B。如：FK_ Employee_ID_ En_OrderDetail_MainID. 外键关联命名基本与索引命名一致。2.7.10. 设计规范. 数据类型为字符串建议使nvarchar，而不用varchar. 字段的集合域：CreatorID、Creator、CreatedTime、UpdaterID、Updater、UpdatedTime. 明细表建议采用复合主键的方式，而不是单独重新创建一个主键。复合主键注意字段的排列顺序。. 如果字段为与其它表相关联为外键，需创建索引。. 如果字段为模糊查询之外的条件，需创建索引。3. 编码规范3.1. C#代码编写3.1.1. 缩进用 SPACES不用TAB，在VS中设置一个TAB为4个SAPACES（默认设置）。在VS中通过Ctrl+E, S可以查看目前缩进使用的符号，通过Ctrl+E，D可以格式化文档。3.1.2. 仅对最需要的类型标记为public，其他的标记为internal3.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. 避免使用大文件。如果一个文件里的代码超过300400行，必须考虑将代码分开到不同类中。3.1.10. 避免写太长的方法。一个典型的方法代码在125行之间。如果一个方法发代码超过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”) = strCurrentUserIPSession(“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. 标记的换行规范： 一个标记必须占用一行。不得出现两个标记在同一行的情况(同一标记的关闭标记除外)，如： text 而必须写成： text 3.3.2. 标记的关闭规范 . 静态文件内容必须包含在标记中间 . 标记必须包含在标记中间 . 对于需要关闭的标记，如： 必须同其关闭标记同时出现。如 . . 不得出现交叉包含的语句，如： . . 标记的属性赋值规范 对于接受属性的标记，属性值必须使用双引号或者单引号包围。如: 注意：必须确保属性的赋值无警告或错误。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. 发生异常