软件编写规范(VC).doc

 一、 风格 2 1.基本要求 2 2.可读性要求 2 3. 结构化要求 3 4. 正确性与容错性要求 3 5. 可重用性要求 4 二、 注释 4 1. 注释使用的语言 4 2.文件开始注释 4 3.方法注释 5 4.程序中注释 5 三、 命名 6 1.命名原则 6 2.类成员变量的命名 6 3.局部变量的命名 6 4.临时变量的命名 7 5.函数名命名 7 6.宏命名和typedef定义类型 7 7.自定义消息 7 8.常量命名 8 9.资源名字定义格式: 8 10.方法命名和命名空间,类的命名,接口的命名 8 11.事件方法的命名: 8 12.接口的命名 9 13.控件的命名： 9 四、 工程文件组织形式 9  风格 1.基本要求 1.1 程序结构清析，简单易懂，单个方法的程序行数不得超过100行。每个方法应该且只应该完成一件事情，方法不应该有副作用。 1.2 打算干什么，要简单，直接了当，代码精简，避免垃圾程序。 1.3 尽量使用标准库和公共方法。 1.4 不要随意定义全局变量，尽量使用局部变量。 2.可读性要求 2.1 可读性第一，效率第二。 2.2 保持注释与代码完全一致。 2.3 每个源程序文件，都有文件头说明，说明规格见规范。 2.4 每个方法，都有方法头说明，说明规格见规范。 2.5 主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。 2.7 常量定义（DEFINE）有相应说明。 2.8 处理过程的每个阶段都有相关注释说明。 2.9 在典型算法前都有注释。 2.10 利用缩进显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为4个字节。 2.11 循环、分支层次不要超过五层。 2.12 注释可以与语句在同一行，也可以在上行。 2.13 空行和空白字符也是一种特殊注释。 2.14 一目了然的语句不加注释。 2.15 注释的作用范围可以为：定义、引用、条件分支以及一段代码。 2.16 注释行数（不包括程序头和方法头说明部份）应占总行数的 1/5 到 1/3 。 2.17程序编码力求简洁，结构清晰，避免太多的分支结构及太过于技巧性的程序. 2.18版本封存以后的修改一定要将做好注释,并要在文件及方法的修改记录中加以记录。 3. 结构化要求 3.1 禁止出现两条等价的支路。 3.2 尽量不采用GOTO语句。 3.3 用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。 3.4 用 CASE 实现多路分支。 3.5 避免从循环引出多个出口。 3.6 方法只有一个出口。 3.7 避免不必要的分支。 3.8 不要轻易用条件分支去替换逻辑表达式。 ３.9 不要轻易使用递归算法，尤其在访问数据库的时候。 3.10 程序中每个block 的开头 ”{ 及 }” 必须对齐，嵌套的block 每进一套， 缩进一个tab，TAB 为4个空格,block类型包括if、for、while、do等关键字引出的结构语句。 3.11 对于比较大的方法，每个block 和特殊的方法调用，都必须注明其功能 4. 正确性与容错性要求 4.1 程序首先是正确，其次是优美 4.2 无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。 4.3 改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。 4.4 所有变量在调用前必须被初始化。 4.5 对所有的用户输入，必须进行合法性检查。 4.6 不要比较浮点数的相等，如： 10.0 * 0.1 == 1.0 ， 不可靠 4.7 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。对于明确的错误,要有明确的容错代码提示用户。 4.8尽量使用编译器已经提供的函数，不必花时间另行编写。例如系统已经有qsort函数，可直接拿来排序用。 4.9 尽量使用规范的容错语句. 例如: try { } catch { } finally { } 5. 可重用性要求 5.1 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。 5.2 公共控件或类应减少外界联系，考虑独立性或封装性。 5.3 公共控件或类应建立使用模板。 注释 1. 注释使用的语言 原则上注释要求使用中文; 2.文件开始注释 内容包括:公司名称、版权、作者名称、时间、模块用途、背景介绍等,复杂的算法需要加上流程说明; 例如: 文件开头的注释模板 /**********************************************************