在网上搜集了一些资料,整理了一下关于华为的编程要求,方便学习
一. 排版
1. 程序块要采用缩进风格编写,缩进的空格数为4个,但对齐只使用空格键,不使用TAB键。
2. 相对独立的程序块之间、变量说明之后必须加空格。
3. 较长的语句要分成多行书写,长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐。
4. 不允许把多个短语句写在一行中。
5. If、for、do、while、case、switch、default等语句自占一行,且if、for、do、while等语句的执行语句部分无论多少都要加括号{},且“{”和“}”各度自占一行,同时与引用它们的语句左对齐。
6. 在两个以上的关键字、变量、常量进行对等操作时,它们之间的操作符之前、之后或者前后要加空格;进行非对等操作时,如果是关系密切的立即操作符(如-> ),后不应加空格。
二. 注释
1. 一般情况下,源程序有效注释量必须在20 %以上。
2. 说明性文件(如头文件.h 文件、.inc 文件、.def 文件、编译说明文件.cfg 等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等,头文件的注释中还应有函数功能简要说明。
3. 源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。
4. 边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。不再有用的注释要删除。
5. 对于所有有物理含义的变量、常量,如果其命名不是充分自注释的,在声明时都必须加以注释,说明其物理含义。变量、常量、宏的注释应放在其上方相邻位置或右方。
6. 将注释与其上面的代码用空行隔开。
7. 对于switch 语句下的case 语句,如果因为特殊情况需要处理完一个case 后进入下一个case 处理,必须在该case 语句处理完、下一个case 语句前加上明确的注释。
8. 避免在一行代码或表达式的中间插入注释。
三. 标识符
1. 标识符的命名要清晰、明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。
2. 命名中若使用特殊约定或缩写,则要有注释说明。
3. 自己特有的命名风格,要自始至终保持一致,不可来回变化。
4. 对于变量命名,禁止取单个字符(如i 、j 、k... ),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但i 、j 、k 作局部循环变量是允许的。
5. 用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
四. 变量、结构
1. 去掉没必要的公共变量。
2. 仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
3. 防止局部变量与公共变量同名。
4. 严禁使用未经初始化的变量作为右值。
5. 构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
6. 使用严格形式定义的、可移植的数据类型,尽量不要使用与具体硬件或软件环境关系密切的变量。
7. 结构的功能要单一,是针对一种事务的抽象。
8. 不要设计面面俱到、非常灵活的数据结构,不同结构间的关系不要过于复杂。
五. 函数、过程
1. 明确函数功能,精确(而不是近似)地实现函数设计。
2. 编写可重入函数时,应注意局部变量的使用,若使用全局变量,则应通过关中断、信号量(即P 、V 操作)等手段对其加以保护。
3. 防止将函数的参数作为工作变量。
4. 一个函数仅完成一件功能,不要设计多用途面面俱到的函数。
5. 避免使用无意义或含义不清的动词为函数命名。
6. 除非必要,最好不要把与函数返回值类型不同的变量,以编译系统默认的转换方式或强制的转换方式作为返回值返回。
7. 功能不明确较小的函数,特别是仅有一个上级函数调用它时,应考虑把它合并到上级函数中,而不必单独存在。
8. 避免使用BOOL 参数。
六. 可测性
1. 在同一项目组或产品组内,要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数,并且要有详细的说明。
2. 编程的同时要为单元测试选择恰当的测试点,并仔细构造测试代码、测试用例,同时给出明确的注释说明。测试代码部分应作为(模块中的)一个子模块,以方便测试代码在模块中的安装与拆卸(通过调测开关)。
3. 使用断言来发现软件问题,提高代码可测性。
4. 对较复杂的断言加上明确的注释。
5. 用调测开关来切换软件的DEBUG 版和正式版,而不要同时存在正式版本和DEBUG 版本的不同源文件,以减少维护的难度。
6. 软件的DEBUG 版本和发行版本应该统一维护,不允许分家,并且要时刻注意保证两个版本在实现功能上的一致性。
7. 调测开关应分为不同级别和类型。