软件编程规范.doc

目 次 前 言 5 1. 范围 6 2. 术语和定义 6 2.1. 原则 6 2.2. 规则 6 2.3. 建议 6 2.4. 说明 6 2.5. 正例 6 2.6. 反例 6 3. 基本原则 6 4. 设计原则 7 5. 布局 7 5.1. 文件布局 7 5.2. 基本格式 9 5.3. 对齐 10 5.4. 空行空格 12 5.5. 断行 14 5.6. PERL文件布局 15 6. 注释 17 7. 命名规则 22 7.1. 基本规则 22 7.2. 文件命名 26 7.3. 模块命名 26 7.4. 函数命名 26 7.5. 事件命名 27 7.6. 变量命名 27 7.7. 常量命名 27 7.8. 资源命名 27 8. 变量，常量与类型 28 8.1. 变量与常量 28 8.2. 类型 31 9. 表达式与语句 36 10. 接口，函数与过程 42 10.1. 接口指南 42 10.1.1. 基本思想 42 10.1.2. 基本原则 42 10.1.3. 返回值 44 10.1.4. 方法 44 10.1.5. 布尔参数 44 10.1.6. 私有的和公共的接口 45 10.1.7. 实用性和重用性 45 10.1.8. 函数 45 10.2. 函数与过程 46 10.2.1. 参数 46 10.2.2. 返回值 47 10.2.3. 内部实现 48 10.2.4. 函数调用 51 11. 文件指南 52 11.1. 头文件 52 11.1.1. General header-file 52 11.1.2. Public-interface header files 53 11.1.3. Regional header files 53 11.1.4. Definition header files 54 11.2. Implementation files 54 12. 任务间通信 54 12.1. 概述 54 12.2. 要求 55 12.3. 指南 56 12.3.1. 利用公开发布的API完成任务间通信的方法 56 12.4. 任务间通信历史方法 57 13. PERL规范 58 13.1. 编码规范 58 13.2. 命名规范 58 13.2.1. 文件命名规范 58 13.2.2. 标识命名规范 59 13.2.3. 形式参数 59 14. 可靠性 59 14.1. 内存使用 60 14.2. 指针使用 62 14.3. 类和函数 63 15. 可测试性 67 16. 断言与错误处理 70 前 言 编写本标准的目的是为了统一软件编程风格，提高软件源程序的可读性、可靠性和可重用性，提高软件源程序的质量和可维护性，减少软件维护成本，最终提高软件产品生产力。 考虑到不同产品和项目的实际开发特性，本规范分成规则性和建议性两种：对于规则性规范，要求所有软件开发人员严格执行；对于建议性规范，各项目编程人员可以根据实际情况选择执行。本规范的示例都以C/C++语言描述。 本规范的内容包括：基本原则、设计原则、布局、注释、命名规则、变量常量与类型、表达式与语句、接口、文件、任务间通讯、可靠性、可测试性、断言与错误处理。 。  基本原则 ● 模块化设计原则：减小模块之间的耦合度。即要对模块进行解耦。如何达到模块之间的耦合度最小，关键是设计模块之间的接口；一个模块实现独立的，通用的，一定原子性的功能；模块实现代码与下层支撑层之间采用标准接口，保证代码的可移植性。 ● 开发的软件要有可读性和可维护性。首先是为人编写程序，其次才是计算机，要考虑到产品的开发，测试，生产，用户使用，版本升级和后期维护等长期过程。 ● 编码格式要遵守文件模板 ● 尽量保证底层源码的完整性 ● 尽量不要改变代码的风格，坚持代码的最初风格 ● 保证软件系统的稳定性，易读性，可修改性，可扩充性，可重用性和可移植性 ● 不必改变以前代码风格以适应新的风格 ● 鼓励多加注释 ● 在代码中避免使用tab，而用空格代替 ● 根据不同的功能来创建源文件 ● 源文件中函数的顺序要符合逻辑 ● 函数本身不要太大，控制在1到2页的范围 ● 保持代码的简明清晰，避免过分的编程技巧 ● 使用C语言的代码要尽可能遵循ANSI C标准 ● 编程首先要考虑代码的正确性、健壮性、可维护性、可移植性等质量因素，最后才考虑程序的效率和资源占用 ● 避免或者少用全局变量，过多地使用全局变量，会导致模块间的紧耦合，违反模块化的要求 ● 尽量避免使用GOTO语句 ● 尽可能重用和修正老的代码 设计原则 ● 当一个模块改变时不应该影响到其它模块的实现 ● 确定代码能否在不同的平台上运行 ● 如果代码中存在条件编译，考虑去除这些条件时的情况 ● 尽量减少程序对工具和硬件的依赖