软件开发编码规范.doc

软件开发编码规范(C#)目录1引言41.1编写目的41.2背景41.3定义41.4参考资料42基本规定42.1程序结构规定42.2可读性规定42.3结构化规定52.4对的性与容错性规定52.5可重用性规定63用户界面设计原则64源程序书写规范64.1通用源代码格式规则64.1.1缩进64.1.2边距74.1.3“{}”的使用74.1.4注释74.2语句格式与语句书写规范74.2.1括号84.2.2保存字和关键字84.2.3函数84.2.4变量84.2.5语句85命名规范105.1函数命名105.2形参105.3常量和变量105.3.1常量和宏定义105.3.2变量105.4函数使用说明、接口命名、NameSpace命名115.5控件的命名125.6类型125.6.1一般类型125.6.2构造类型135.6.3类类型135.7文献和文献夹135.7.1文献夹的命名规则135.7.2文献命名146源程序文档注释规范146.1注释文档的一般规范14引言编写目的本规范旨在用规范文献的形式，对全公司使用C#进行的编程过程，进行有效的规范管理，使得最终的软件产品具有良好的风格和统一的结构，且使代码可读性强、易维护。本规范预期读者是全公司所有参与编程的软件开发人员以及其他相关人员。本标准合用于VisualC#,其余语言作参考。背景公司在上一个项目中由于代码编写风格不统一，可读性较差、较难维护，使得工作效率有所减少。定义无参考资料PascalStandardsFAQ(E)JavaDoc（E）Doc-O-maticDocument(E)ArtemisAllianceDelphiCodingStandards(E)《C#基本书写规范》《C#编码规范纲要》基本规定程序结构规定程序结构清楚，简朴易懂，单个函数的程序行数一般不得超过100行,个别特殊函数除外。代码中打算干什么，要简朴，直接了当，代码精简，避免垃圾程序。应尽量使用.NET库函数和公共函数(无特殊情况不要使用外部方法调用windows的核心动态链接库)。一般情况下，不得使用全局变量，尽量使用局部变量。可读性规定可读性第一，效率第二。（这仅对代码自身而言）。保持注释与代码完全一致。每个源程序文献，都必须有文献头说明，说明规格见“源程序文档注释规范”一节。每个函数，都必须有函数头说明，说明规格见“源程序文档注释规范”一节。重要变量（结构、联合、类或对象）定义或引用时，注释必须能反映其物理含义。解决过程的每个阶段都必须有相关注释说明。在典型算法前都必须有注释,同时算法在满足规定的情况下应尽也许简朴。运用缩进来显示程序的逻辑结构，缩进量一致以Tab键为单位，定义Tab为4个字节。循环、分支层次不要超过五层。注释可以与语句在同一行，也可以在上行。空行和空白字符也是一种特殊注释。一目了然的语句不加注释。注释的作用范围可认为：定义、引用、条件分支以及一段代码。注释行数（不涉及文献头和函数头说明部份）应占总行数的1/5到1/3。常量定义（const）有相应说明。结构化规定严禁出现两条等价的支路。严禁GOTO语句。用IF语句来强调只执行两组语句中的一组。严禁ELSEGOTO和ELSERETURN。用CASE实现多路分支。避免从循环引出多个出口。函数只有一个出口。不使用复杂的条件赋值语句。避免不必要的分支。不要容易用条件分支去替换逻辑表达式。对的性与容错性规定程序一方面是对的，另一方面是优美。无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。改一个错误时也许产生新的错误，因此在修改前一方面考虑对其它程序的影响。所有变量在调用前必须被初始化。对所有的用户输入，必须进行合法性检查。不要比较浮点数的相等，如：10.0*0.1==1.0，不可靠。程序与环境或状态发生关系时，必须积极去解决发生的意外事件，如文献能否逻辑锁定、打印机是否联机等,对于明确的错误,要有明确的容错代码提醒用户。单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。尽量使用规范的容错语句。例如:try{}catch{}finally{}可重用性规定反复使用的完毕相对独立功能的算法或代码应抽象为服务或类。服务或类应考虑面向对象(OO)思想，减少外界联系，考虑独立性或封装性。用户界面设计原则除标题部分外，所有显示给用户的字体（如BUTTON和LABEL等）使用标准字体：宋体、九号、黑色；标题部分可用醒目的字体，如：宋体、小二号、红色。采用Windows缺省的风格。窗体尽量从已有的父窗体继承。方便用户对信息的输入、修改和阅读。验证用户输入的有效性和合理性。具有清楚明确的用户提醒信息。使用Tab键在输入项之间移动输入焦点（可选）。标准按钮大小必须相同，使用的图像和标题必须与《界面风格规范》一致，假如出现该规范中没有的地方，须与项目负