软件编程规范(MIRA_C).docVIP

软 件 编 程 规 范 目 录 一 环境 二 语言扩展 三 文档 四 字符集 五 标识符 六 类型 七 常量 八 声明与定义 九 初始化 十 数值类型转换 十一 指针类型转换 十二 表达式 十三 控制语句表达式 十四 控制流 十五 switch语句 十六 函数 十七 指针和数组 十八 结构与联合 十九 预处理指令 二十 标准库 二十一 运行时错误 一 环境 规则1.1（强制）： 所有代码都必须遵照ISO 9899:1990 “Programming languages - C”，由ISO/IEC 9899/COR1:1995，ISO/IEC 9899/AMD1:1995，和ISO/IEC9899/COR2:1996 修订。 规则1.2（强制）： 不能有对未定义行为或未指定行为的依赖性。 这项规则要求任何对未定义行为或未指定行为的依赖，除非在其他规则中做了特殊说明，都应该避免。如果其他某项规则中声明了某个特殊行为，那么就只有这项特定规则在其需要时给出背离性。 规则1.3（强制）： 多个编译器和/或语言只能在为语言/编译器/汇编器所适合的目标代码定义了通用接口标准时使用。 如果一个模块是以非C 语言实现的或是以不同的C 编译器编译的，那么必须要保证该模块能够正确地同其他模块集成。C 语言行为的某些特征依赖于编译器，于是这些行为必须能够为使用的编译器所理解。例如：栈的使用、参数的传递和数据值的存储方式（长度、排列、别名、覆盖，等等）。 规则1.4（强制）： 编译器/链接器要确保31 个有效字符和大小写敏感能被外部标识符支持。 ISO 标准要求外部标识符的头6 个字符是截然不同的。然而由于大多数编译器/链接器允许至少31 个有效字符（如同内部标识符），因此对这样严格而并不具有帮助性的限制的适应性被认为是不必要的 。 必须检查编译器/链接器具有这种特性，如果编译器/链接器不能满足这种限制，就使用编译器本身的约束。 规则1.5（建议）： 浮点应用应该适应于已定义的浮点标准 浮点运算会带来许多问题，一些问题（而不是全部）可以通过适应已定义的标准来克服。其中一个合适的标准是 ANSI/IEEE Std 754 [21]。 同规则6.3 相一致，浮点类型的定义提供了一个注释所用浮点标准的机会，如： /* IEEE 754 single-precision floating-point */ typedef float float32_t; 二 语言扩展 规则2.1（强制）： 汇编语言应该被封装并隔离。 在需要使用汇编指令的地方，建议以如下方式封装并隔离这些指令：(a) 汇编函数、(b) C函数、(c) 宏。 出于效率的考虑，有时必须要嵌入一些简单的汇编指令，如开关中断。如果不管出于什么原因需要这样做，那么最好使用宏来完成。 需要注意的是，内嵌的汇编语言的使用是对标准C 的扩展，因此也需要提出对规则1.1的背离。 #define NOP asm (“ NOP”); 规则2.2（强制）： 源代码应该使用 /*…*/ 类型的注释。 这排除了如 // 这样C99 类型的注释和C++类型的注释，因为它在C90 中是不允许的。许多编译器支持 // 类型的注释以做为对C90 的扩展。预处理指令（如#define）中 // 的使用可以改变，/*…*/和//的混合使用也是不一致的。这不仅是类型问题，因为不同的编译器（在C99之前）可能会有不同的行为。 规则2.3（强制）： 字符序列 /* 不应出现在注释中。 C 不支持注释的嵌套，尽管一些编译器支持它以做为语言扩展。一段注释以/*开头，直到第一个*/为止，在这当中出现的任何/*都违反了本规则。考虑如下代码段： /* some comment, end comment marker accidentally omitted New Page Perform_Critical_Safety_Function (X); /* this comment is not compliant */ 在检查包含函数调用的页中，假设它是可执行代码。因为可能会省略掉注释的结束标记，那么对安全关键函数的调用将不会被执行。 规则2.4（建议）： 代码段不应被“注释掉”（comment out）。 当源代码段不需要被编译时，应该使用条件编译来完成（如带有注释的#if 或#ifdef 结构）。为这种目的使用注释的开始和结束标记是危险的，因为C 不支持嵌套的注释，而且已经存在于代码段中的任何注释将影响执行的结果。 三 文档 规