MISRA 2004规则

Jerry整理<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

出处：汽车工业软件可靠性联会

最后更新时间：2005-7-20

转载请注明：来自Sawin系统分析之窗

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的基础上适当修改就可以形成自己的规范。当然其中也有一些过于严苛的东西，这就需要各个开发部门灵活处理了。我个人的体会，编码规范虽然很简单，但是要完全执行，不折不扣，需要开发部门有很高的组织性和纪律性，并且有很好的代码评审机制。因此，如果能够严格地遵守编码规范，本身就是一个开发部门实力的证明。 内容 <环境>

Rule1.1（强制）:所有的代码应该遵守ISO 9899:1990“Programming Language C”

Rule1.2（强制）:只有当具备统一接口的目标代码的时候才可以采用多种编译器和语言

Rule1.4（强制） 检查编译器/连接器以确保支持31一个有效字符，支持大小写敏感

<语言扩展>

Rule 2.1(强制)：汇编语言应该封装起来并且隔离：

例如：#define NOP asm(“ NOP”)

Rule 2.2(强制) :源代码只能采用/*…*/风格的注释

Rule2.3(强制): 字符序列/*不能在注释中使用

注:C语言不支持注释的嵌套即使一些编译器支持这个语言扩展

Rule 2.4(建议)：代码段不能注释掉

注：应采用#IF 或者#ifdef来构成一个注释，否则代码里如果有注释会改变代码的作用

<文档化>

Rule 3.3(建议)：编译器对于整数除法运算的实施应该写入文档

例编译器：-5/3 = -1 余-2 有些编译器结果是-2于＋1

<字符集>

Rule 4.1(强制)：只能使用ISO标准定义的字符集

<标识符>

Rule6.5 (强制):在内部范围的标识符不能和外部的标识符用同样的名字，因为会隐藏那个标识符

例：

Int16_t i:

Void f()

{

int16_t I;

i=3；

}

Rule 5.2(强制): typedef 名称只能唯一，不能重复定义

Rule 5.4(强制): 标记名应该是唯一的标识符

Rule 5.7(建议):标识符不能重复使用

<类型>

Rule 6.1(强制):Char类型只能用来存储使用字符

Rule 6.2(强制):signed和unsigned char 只能用来存储和使用数据值

Rule6.3(建议)对于基本的类型使用Typedef来表示大小和有无符号

例：

Typedef char char_t

Typedef signed int int32_t

<约束>

Rule 7.1(强制)：不要用八进制数

注:整型常数以”0“开始会被认为是8进制

例：code[1]=109

code[2]=100

code[3]=052

code[4]=071

如果是对总线消息初始化，会有危险

<声明和定义>

Rule 8.1(强制)：函数都应该有原型声明，且相对函数定义和调用可见

Rule8.2 (强制)：无论何时一个对象和函数声明或者定义，它的类型应该明确声明

Rule 8.5(强制):头文件中不要定义对象或者函数

Rule8.3(强制)：每个函数声明中的参数的类型应该和定义中的类型一致

Rule 8.8(强制):外部变量或者函数只能声明在一个文件中

注：一般来讲，声明在头文件中，然后包含在定义和使用的文件中

Rule 8.12(强制)：数组声明为外部，应该明确声明大小或者直接初始化确定

例：extern int array2[ ] /* 违反Rule8.8 */

<初始化>

Rule 9.1(强制):所有变量在使用之前都应该赋值

<数学类型转换(隐式)>

Rule 10.1(强制):整型表达式不要隐式转换为其他类型：

a）转换到更大的整型

b）表达式太复杂

c）表达式不是常数是一个函数

d）表达式不是一个常数是一个返回表达式

Rule 10.2(强制)：浮点数表达式不要隐式转换为其他类型：

a）转换到更大的浮点数

b）表达式太复杂

c）表达式是一个函数

d）表达式是一个返回表达式

<数学类型转换(明确)>

Rule 10.3(强制):整型表达式的值只能转换到更窄小且是同样符号类型的表达式

Rule 10.4(强制):浮点表达式的值只能转换到更窄小的浮点表达式

<数学类型转换>

Rule 10.6(强制):所有的 unsigned类型都应该有后缀”U“

Rule 11.1(强制)：指针不能转换为函数或者整型以外的其他类型

<表达式>

Rule12.2(强制)：表达式的值应和标准允许的评估顺序一致

例：

X=b[i] + i++;

不同的编译器给出的结果不一样，b[i]是否先执行？

应：x=b[i];

i++;

比如：

X=func(i++,i);

Rule12.3(强制):sizeof操作符不能用在包含边界作用(side effect)的表达式上

例:

Int32_t=i;

Int32_t=j;

j=sizeof(i=1234);

表达式并没有执行，只是得到表达式类型int的size

Rule 12.4(强制)：逻辑操作符&&或者||右边不能包含边界作用(side effect)

例：

If(ishight) && (x== i++)),如果ishight＝0那么i++不会评估

Rule 12.3(建议)：++和- -不能和其他表达式用在一个表达式中

例：

U8a=++u8b + u8c--;

<控制语句表达式>

Rule13.1(强制)：赋值语句不能用在一个产生布尔值的表达式中

例：

If((x=y)!=0)…

更差：

If (x=y)…

Rule13.3(强制):浮点表达式不应该测试其是否相等或者不相等

Rule13.4(强制):for控制表达式中不要包含任何浮点类型

Rule13.6(强制):数字变量作为for循环的循环计数不要在循环体内部被修改

例：

Flag=1;

For(i=0;(i<5)&&(flag==1);i++)

{

Flag=0;

i=i+3;

}

<控制流>

Rule 14.1(强制):不要有执行不到的代码

例：

Swich(event)

{

Case www;

do_wakeup();

break;

do_more();

…

}

Rule 14.4(强制)：goto语句不能使用

Rule 14.5(强制)：continue不能使用

Rule 14.6(强制):函数应在函数结束有一个出口

Rule 14.7(强制)：witch,while,do ...while,for语句体应是一个混合语句(括号)

Rule 14.10(强制):所有if…else if结构都应该由else结束

<Switch语句>

Rule 15.3(强制)：switch的最后应是default

Rule 15.4(强制)：switch表达式不能使用布尔表达式

例：

Switch(x==0)

{

… …

}

Rule 15.5(强制)：每一个Switch语句都应该有一个case

例：

Switch(x)

{

Uint8_t var; /* 违反*/

Case 0:

A=b;

…

}

<函数>

Rule16.2(强制color