软件开发编码规范DOC.docxVIP

软件开发编码规范

(C#)

目 录

TOC\o1-3\h\z\u引言 3

编写目的 3

背景 3

定义 3

参考资料 3

基本要求 3

程序结构要求 3

可读性要求 3

结构化要求 4

正确性与容错性要求 4

可重用性要求 5

用户界面设计原则 5

源程序书写规范 5

通用源代码格式规则 5

缩进 5

边距 6

“{}”的使用 6

注释 6

语句格式与语句书写规范 6

括号 6

保留字和关键字 7

函数 7

变量 7

语句 7

命名规范 9

函数命名 9

形参 9

常量和变量 9

常量和宏定义 9

变量 9

函数使用说明、接口命名、NameSpace命名 10

控件的命名 11

类型 11

一般类型 11

构造类型 12

类类型 12

文件和文件夹 12

文件夹的命名规则 12

文件命名 13

源程序文档注释规范 13

注释文档的一般规范 13

引言

编写目的

本规范旨在用规范文件的形式，对全公司使用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等）使用标准字体：宋体、九号、黑色；标题部分可用醒目的字体，如：宋体、小二号、红色