2. MISRA C基础概念

各位同学，欢迎来到第二章。上一章我们聊了MISRA C的起源和它为什么重要。今天，咱们要深入它的“骨架”——也就是编码规范的核心原则。

说实话，我刚接触MISRA C的时候，第一反应是：“这玩意儿怎么这么多条？背都背不下来。” 后来我才明白，光背条文没用，你得理解它背后的分类逻辑。理解了分类，你才知道哪些是“死命令”，哪些是“建议”，哪些是“最好别这么干”。

规则与建议：一字之差，天壤之别

MISRA C把所有的条款分成了两大类：规则（Rule） 和 建议（Directive）。别看都是“规定”，性质完全不同。

举个例子。规则里有一条：“不得使用未初始化的变量”。这是铁律。你想想看，一个未初始化的局部变量，它的值是不确定的。在嵌入式系统里，这可能导致设备随机重启、误动作。我在项目中遇到过，一个同事因为忘了初始化一个标志位，导致整个状态机跑飞，查了整整两天。这种错误，静态分析工具一扫描就能揪出来。

而建议呢？比如：“建议使用括号明确表达式优先级”。你写 a + b << 2，编译器能编译，结果也对。但别人看代码，或者你三个月后回来看，就得猜：到底是 (a + b) << 2 还是 a + (b << 2)？这种代码，工具不会报错，但容易埋下隐患。我个人习惯，只要涉及混合运算，一律加括号。这不是强制要求，但能救命。

违反规则的严重性等级：Mandatory / Required / Advisory

光分规则和建议还不够。MISRA C还给每条规则标了“严重等级”。这就像交通法规：闯红灯是严重违章，违停是轻微违章，但都得管。

等级分为三级：

• 强制（Mandatory）：没有任何商量余地。违反即违规，必须修改。比如“不得使用动态内存分配”。在嵌入式系统里，malloc/free 是魔鬼，会导致堆碎片、内存泄漏，甚至系统崩溃。我见过一个项目，因为用了malloc，跑了72小时后系统挂了。从那以后，我对Mandatory规则绝对服从。
• 必需（Required）：必须遵守，但允许有理由的偏离。你需要提交一份“偏离申请”，说明为什么违反，以及如何控制风险。比如“函数参数个数不得超过5个”。如果你有一个函数确实需要6个参数，可以，但必须经过评审和批准。
• 建议（Advisory）：推荐遵守，但偏离不需要正式申请。比如“建议使用switch语句时包含default分支”。如果你能确保所有case都覆盖了，不写default也行。但我会建议你写上，哪怕只是放个断言，防止未来有人加了一个新case忘了处理。

规则分类体系：从“是什么”到“为什么”

MISRA C 2012 把规则分成了21个类别。别被数字吓到，其实可以归纳为几个大方向。我画了一张图，帮你理清脉络。

你看，这张图把规则分成了四大块：

1. 语言核心：包括类型系统、表达式求值、副作用。说白了，就是C语言本身容易出坑的地方。比如“不得依赖求值顺序”，我见过有人写 a[i] = i++;，结果不同编译器结果不同，这就是典型的未定义行为。
2. 声明与定义：包括作用域、初始化、类型转换。比如“所有变量必须在使用前初始化”，这条规则救过我无数次。
3. 控制流：包括循环、条件分支、跳转。比如“switch语句中每个case必须用break结束”，防止“穿透”导致逻辑错误。
4. 指针与内存：包括指针运算、动态内存、空指针。嵌入式系统里，指针用不好，就是灾难。