2. 编码规则总览：MISRA C规则分类与体系

MISRA C的规则体系，说白了就是一套“交通规则”。它告诉你哪些写法是禁区，哪些是建议。我刚开始接触MISRA C时，面对几百条规则也头大。但摸清它的分类逻辑后，事情就简单多了。

这一章，我们就把这套规则体系拆开来看。规则怎么分级的？编号有什么门道？违反规则后果有多严重？搞懂这些，你再看具体规则就不会晕了。

2.1 规则的三个等级：强制、必要、建议

MISRA C把规则分成三个等级。每个等级代表不同的“强制力”。

等级	英文术语	含义	违反后果
强制	Required	必须遵守，没有例外	直接违反标准，需偏差申请
必要	Mandatory	必须遵守，但允许偏差	需书面说明理由并审批
建议	Advisory	推荐遵守，非强制	建议采纳，不强制整改

我在项目中遇到过不少团队，把“建议”规则直接忽略。结果代码评审时被客户揪出来，说你们连建议规则都不遵守，质量意识堪忧。所以我的建议是：建议规则也尽量遵守，除非有充分理由。

2.2 规则编号体系：一眼看懂规则归属

MISRA C的规则编号不是乱来的。它有一套清晰的编码逻辑。你看到编号，就能猜到这条规则在说什么。

编号格式是：Dir X.Y 或 Rule X.Y。

• Dir：指导性规则（Directive），偏向流程、文档、工具链
• Rule：具体编码规则，直接约束代码写法

后面的数字，第一位是章节号，第二位是序号。比如 Rule 10.1，就是第10章的第1条规则。

MISRA C:2012 一共有 16条指导性规则（Dir） 和 143条编码规则（Rule）。其中强制规则约占60%，必要规则约占30%，建议规则约占10%。

2.3 规则违反的严重等级

违反规则不是“一刀切”的后果。MISRA C定义了三个严重等级，用来评估违规的影响。

严重等级	描述	典型场景
严重	可能导致未定义行为或安全风险	数组越界、空指针解引用
中等	可能导致可预测但非预期的行为	隐式类型转换、未初始化变量
轻微	影响可读性或可维护性	命名不规范、注释缺失

我曾经在一个汽车ECU项目里，遇到一条 Rule 18.1（指针运算）的违规。静态分析工具报的是“中等”。但评审时发现，这个指针运算在特定条件下会越界，直接导致系统死机。最后我们把它升级为“严重”处理。所以，工具给出的等级只是参考，最终判断要靠人。

2.4 规则分类总览图

下面这张图，把MISRA C的规则体系串起来了。你可以看到规则从“分类”到“等级”再到“严重性”的完整脉络。

2.5 实际项目中的规则应用策略

光知道分类还不够。你得知道在项目里怎么落地。我总结了一套“三步走”策略：

1. 先扫强制规则：用静态分析工具跑一遍，把强制违规全部清零。这是底线。
2. 再处理必要规则：逐条评审，能改就改。确实改不了的，走偏差申请流程，留下书面记录。
3. 最后看建议规则：团队内部定个标准，能遵守就遵守。实在做不到，至少知道风险在哪。

2.6 常见误区与避坑指南

这些年我见过不少团队在规则应用上翻车。这里列几个典型误区：

• 误区一：强制规则必须100%遵守——其实不是。强制规则也可以申请偏差，但理由必须充分，审批必须严格。
• 误区二：建议规则可以完全忽略——我见过一个项目，因为忽略建议规则，代码评审被客户打回重做。建议规则是“建议”，但客户可能把它当“要求”。
• 误区三：严重等级由工具说了算——工具只是辅助。最终判定要靠人工评审。同一个违规，在不同上下文里严重程度可能完全不同。