软件开发编码规范

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件开发编码规范(C#)

目录

1 引言 (4)

1.1 编写目的 (4)

1.2 背景 (4)

1.3 定义 (4)

1.4 参考资料 (4)

2 基本要求 (4)

2.1 程序结构要求 (4)

2.2 可读性要求 (4)

2.3 结构化要求 (5)

2.4 正确性与容错性要求 (5)

2.5 可重用性要求 (6)

3 用户界面设计原则 (6)

4 源程序书写规范 (6)

4.1 通用源代码格式规则 (6)

4.1.1 缩进 (6)

4.1.2 边距 (7)

4.1.3 “{}”的使用 (7)

4.1.4 注释 (7)

4.2 语句格式与语句书写规范 (7)

4.2.1 括号 (8)

4.2.2 保留字和关键字 (8)

4.2.3 函数 (8)

4.2.4 变量 (8)

4.2.5 语句 (8)

5 命名规范 (10)

5.1 函数命名 (10)

5.2 形参 (10)

5.3 常量和变量 (10)

5.3.1 常量和宏定义 (10)

5.3.2 变量 (10)

5.4 函数使用说明、接口命名、NameSpace命名 (11)

5.5 控件的命名 (12)

5.6 类型 (12)

5.6.1 一般类型 (12)

5.6.2 构造类型 (13)

5.6.3 类类型 (13)

5.7 文件和文件夹 (13)

5.7.1 文件夹的命名规则 (13)

5.7.2 文件命名 (14)

6 源程序文档注释规范 (14)

6.1 注释文档的一般规范 (14)

1引言

1.1编写目的

本规范旨在用规范文件的形式,对全公司使用C#进行的编程过程,进行有效的规范管理,使得最终的软件产品具有良好的风格和统一的结构,且使代码可读性强、易维护。

本规范预期读者是全公司所有参与编程的软件开发人员以及其他相关人员。

本标准适用于Visual C# ,其余语言作参考。

1.2背景

公司在上一个项目中由于代码编写风格不统一,可读性较差、较难维护,使得工作效率有所降低。

1.3定义

1.4参考资料

Pascal Standards FAQ (E)

JavaDoc (E)

Doc-O-matic Document (E)

Artemis Alliance Delphi Coding Standards (E)

《C#基本书写规范》

《C#编码规范纲要》

2基本要求

2.1程序结构要求

程序结构清晰,简单易懂,单个函数的程序行数一般不得超过100行,个别特殊函数除外。

代码中打算干什么,要简单,直接了当,代码精简,避免垃圾程序。

应尽量使用.NET库函数和公共函数(无特殊情况不要使用外部方法调用windows的核心动态链接库)。

一般情况下,不得使用全局变量,尽量使用局部变量。

2.2可读性要求

可读性第一,效率第二。(这仅对代码本身而言)。

保持注释与代码完全一致。

每个源程序文件,都必须有文件头说明,说明规格见“源程序文档注释规范”一节。

每个函数,都必须有函数头说明,说明规格见“源程序文档注释规范”一节。

主要变量(结构、联合、类或对象)定义或引用时,注释必须能反映其物理含义。

处理过程的每个阶段都必须有相关注释说明。

在典型算法前都必须有注释, 同时算法在满足要求的情况下应尽可能简单。

利用缩进来显示程序的逻辑结构,缩进量一致以Tab键为单位,定义Tab为 4个

字节。

循环、分支层次不要超过五层。

注释可以与语句在同一行,也可以在上行。

空行和空白字符也是一种特殊注释。

一目了然的语句不加注释。

注释的作用范围可以为:定义、引用、条件分支以及一段代码。

注释行数(不包括文件头和函数头说明部份)应占总行数的 1/5 到 1/3。

常量定义(const)有相应说明。

2.3结构化要求

禁止出现两条等价的支路。

禁止GOTO语句。

用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。

用 CASE 实现多路分支。

避免从循环引出多个出口。

函数只有一个出口。

不使用复杂的条件赋值语句。

避免不必要的分支。

不要轻易用条件分支去替换逻辑表达式。

2.4正确性与容错性要求

程序首先是正确,其次是优美。

无法证明你的程序没有错误,因此在编写完一段程序后,应先回头检查。

改一个错误时可能产生新的错误,因此在修改前首先考虑对其它程序的影响。

所有变量在调用前必须被初始化。

对所有的用户输入,必须进行合法性检查。

不要比较浮点数的相等,如: 10.0 * 0.1 == 1.0 ,不可靠。

程序与环境或状态发生关系时,必须主动去处理发生的意外事件,如文件能否逻辑

锁定、打印机是否联机等,对于明确的错误,要有明确的容错代码提示用户。

单元测试也是编程的一部份,提交联调测试的程序必须通过单元测试。

尽量使用规范的容错语句。

例如:

try

{

}

相关文档
最新文档