摘要：
(1)用宏定义表达式时，要使用完备的括号。示例：如下定义的宏都存在一定的风险。 #define RECTANGLE_AREA( a, b ) a * b #define RECTANGLE_AREA( a, b ) (a * b) #define RECTANGLE_AREA( a, b ) (a) 阅读全文
摘要：
(1)单元测试要求至少达到语句覆盖。 (2)单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。 (3)清理、整理或优化后的代码要经过审查及测试。 (4)代码版本升级要经过严格测试。 (5)使用工具软件对代码版本进行维护。 (6)正式版本上软件的任何修改都应有详细的文档记录。 (7)发现错误立即 阅读全文
摘要：
(1)打开编译器的所有告警开关对程序进行编译。 (2)在产品软件(项目组)中，要统一编译开关选项。 (3)通过代码走读及审查方式对代码进行检查。代码走读主要是对程序的编程风格如注释、命名等以及编程时易出错的内容进行检查，可由开发人员自己或开发人员交叉的方式进行；代码审查主要是对程序实现的功能及程序的 阅读全文
摘要：
(1)在软件设计过程中构筑软件质量。 (2)代码质量保证优先原则： ①正确性，指程序要实现设计要求的功能。 ②稳定性、安全性，指程序稳定、可靠、安全。 ③可测试性，指程序要具有良好的可测试性。 ④规范/可读性，指程序书写风格、命名规则等要符合规范。 (3)只引用属于自己的存贮空间。若模块封装的较好， 阅读全文
摘要：
在保证软件系统的正确性、稳定性、可读性及可测性的前提下，提高代码效率。不能一味地追求代码效率，而对软件的正确性、稳定性、可读性及可测性造成影响。 阅读全文
摘要：
7.1 准备测试代码、测试用例 (1)编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为(模块中的)一个子模块，以方便测试代码在模块中的安装与拆卸(通过调测开关) (2)在进行集成测试/ 系统联调之前，要构造好测试环境、测试项目及测试用例 阅读全文
摘要：
6.1 函数的功能与规模设计 函数应当短而精美，而且只做一件事。不要设计多用途面面俱到的函数，多功能集于一身的函数，很可能使函数的理解、测试、维护等变得困难。 6.2 函数的返回值 (1)对于函数的返回位置，尽量保持单一性，即一个函数尽量做到只有一个返回位置。(单入口单出口)。 要求大家统一函数的返 阅读全文
摘要：
5.1 谨慎使用全局(公共)变量 (1)去掉没必要的公共变量。公共变量是增大模块间耦合的原因之一，故应减少没必要的公共变量以降低模块间的耦合度。 (2)仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。在对变量声明的同时，应对其含义、作用及取值范围进行注释说明，同时若有必要还应说明与其 阅读全文
摘要：
4.1使用有意义的标识，避免直接使用数字 避免使用不易理解的数字，用有意义的标识来替代。涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的枚举或宏来代替。 示例：如下的程序可读性差。 if (Trunk[index].trunk_state == 0) { Trunk[index] 阅读全文
摘要：
3.1 命名的基本原则 标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解——尽量采用采用英文单词或全部中文全拼表示 3.2 变量名的命名规则 (1)变量的命名规则要求用“匈牙利法则”。即开头字母用变量的类型，其余部分用变量的英文意思、英文的缩写、中文 阅读全文
摘要：
2.1 注释的原则 注释的目的是解释代码的目的、功能和采用的方法，提供代码以外的信息，帮助读者理解代码，防止没必要的重复注释信息。 示例：如下注释意义不大。 /* if receive_flag is TRUE */ if (receive_flag) 而如下的注释则给出了额外有用的信息。 /* i 阅读全文
摘要：
1.1 严格采用阶梯层次组织程序代码 各层次缩进的风格采用TAB缩进(TAB宽度原则上使用系统默认值) 1.2空行 (1)变量说明之后必须加空行。 (2)相对独立的程序块之间应加空行。 1.3 对变量的定义，尽量位于函数的开始位置 (1)应避免分散定义变量。 (2)同一类的变量在同一行内定义，或者在 阅读全文
摘要：
编程规范概要 1、 程序结构清析，简单易懂，单个函数的程序行数不得超过100行。 2、 打算干什么，要简单，直截了当，代码精简，避免垃圾程序。 3、 尽量使用标准库函数和公共函数。 4、 不要随意定义全局变量，尽量使用局部变量。 5、 使用括号以避免二义性。 可读性要求 1、可读性第一，效率第二。 阅读全文