MISRA--作为工业标准的C编程规范.docVIP

MISRA--作为工业标准的C编程规范 ??? MISRA (The Motor Industry Software Reliability Association 汽车工业软件可靠性联会) 是位于英国的一个跨国汽车工业协会，其成员包括了大部分欧美汽车生产商。其核心使命是为汽车工业提供服务和协助，帮助厂方开发安全的、高可靠性的嵌入式软件。这个组织最出名的成果是所谓的MISRA C Coding Standard，这一标准中包括了127条C语言编码标准，通常认为，如果能够完全遵守这些标准，则你的C代码是易读、可靠、可移植和易于维护的。最近很多嵌入式开发者都以MISRA C来衡量自己的编码风格，比如著名的uC/OS-II就得意地宣称自己99％遵守MISRA标准。而《嵌入式开发杂志》也专门载文号召大家学习。编码规范通常是一个公司自定的“土政策”，居然有人去做标准，而且还得到广泛的认可，这不禁引起我强烈的兴趣。可惜这份标准的文本需要花钱去买，而且短短几十页，要价非常昂贵。MISRA在网上公布了一些文档，其中有关于MISRA C Coding Standard的Clarification报告，从中间你可以大致猜到MISRA标准本身是什么。我仔细阅读了这些文档，并且通过阅读其他一些介绍性文档，大致了解了MISRA标准的主要内容。这些条款确有过人之处，对于C/C++语言工程项目的代码质量管理能够起到良好的指导性作用，对于大部分软件开发企业来说，在MISRA的基础上适当修改就可以形成自己的规范。当然其中也有一些过于严苛的东西，这就需要各个开发部门灵活处理了。我个人的体会，编码规范虽然很简单，但是要完全执行，不折不扣，需要开发部门有很高的组织性和纪律性，并且有很好的代码评审机制。因此，如果能够严格地遵守编码规范，本身就是一个开发部门实力的证明。 这里不可能将所有规则一一列出（事实上正式文本我一条也没看到），只列出一些比较有意思的条款，让大家有机会了解MISRA的风格。具体的内容，感兴趣的朋友可以自己到.uk去了解。 Rule 1. 严格遵循ANSI C89标准，不允许任何扩展。 Rule 3. 如果要嵌入汇编语言，则必须将所有汇编语句包装在C函数里，而且这些函数中只有汇编语句，没有常规C语句。 ??? Rule 7. 不得使用三元操作符（? : ) Rule 10. 不得残留被注释掉的废代码。 Rule 11. 所有标识符不超过31字符。 Rule 12. 不同名空间中的变量名不得相同。 ???????? 例如： ???????????? typedef struct MyStruct {... } MyStruct; (违规） ???????????? struct Person { ?????????????? char* name; ?????????????? ... ???????????? }; ???????????? char name[32]; （违规） Rule 13. 不得使用char, int, float, double, long等基本类型，应该用自己定义的类型显示表示类型的大小，如CHAR8, UCHAR8, INT16, INT32, FLOAT32, LONG64, ULONG64等。 Rule 14. 不得使用类型char，必须显示声明为unsigned char或者signed char。 Rule 18. 所有数字常数应当加上合适的后缀表示类型，例如51L, 42U, 34.12F等。 Rule 19. 禁止使用八进制数。（因为086U这样的常数很容易引起误解）。 Rule 21. 不得定义与外部作用域中某个标识符同名的对象，以避免遮盖外部作用域中的标识符。 Rule 23. 具有文件作用域的对象尽量声名为static的。 Rule 24. 在同一个编译单元中，同一个标识符不应该同事具有内部链接和外部链接的声名。 ???????? 这里我略作说明： ??????? ???????? 我们通常将一些放在头文件里的变量声名为“外部链接”的，如： ???????? extern UINT32 g_count; // 俗话叫变量声明（对应于变量定义，不分配实际空间） ???????? 对于“使用”这个变量的.c文件来说，这很好，因为g_count始终保持外部链接性质。可是对于定义g_count（实际分配空间）的.c文件来说，如果包含了上述的头文件，则在这个编译单元里就发生了内部链接和外部链接的冲突。解决办法是，定义g_count的文件尽量不要包含声名g_count的头文件。个人感觉这不是任何时候都做得到的，尤其是在对付遗留代码的时候。 Rule 25. 具有外部链接性质的标识符应该只声明一次。 Rule 27