MISRA C2012 核心规则体系：分类、编号与文档结构
好，咱们进入第二章。上一章我聊了聊 MISRA 的来龙去脉，这一章咱们得把它的“骨架”摸清楚。说白了，就是搞清楚 MISRA C2012 那几百条规则到底是怎么组织的。你想想看，如果连规则怎么分类、怎么编号都搞不明白，那落地的时候肯定抓瞎。
我个人习惯，拿到一份 MISRA 文档，第一件事不是去背规则，而是先看它的目录结构和分类逻辑。这就好比你要用一把瑞士军刀，总得先知道哪个是主刀、哪个是开瓶器吧？
规则分类：强制、必要、建议
MISRA C2012 把规则分成了三个等级。这个等级直接决定了你在项目里能不能“通融”。
| 分类 | 英文术语 | 含义 | 我的理解 |
|---|---|---|---|
| 强制 | Mandatory | 必须遵守，没有例外 | 这是底线，碰了就违规 |
| 必要 | Required | 必须遵守，但允许申请偏差 | 大部分情况要守，特殊情况可以打报告 |
| 建议 | Advisory | 建议遵守，不强制 | 听人劝，吃饱饭 |
关键点： 强制规则是“一票否决制”。我在项目中遇到过，有个同事觉得某条强制规则“太死板”，偷偷绕过去了。结果代码评审的时候被 QA 抓个正着，直接打回重改。嗯，从那以后，没人再敢挑战强制规则。
我的建议： 对于“建议”类规则，别因为它不强制就完全忽略。很多建议规则其实是为了代码的可读性和可维护性。我曾经在一个维护了 5 年的老项目里，就因为一条建议规则没遵守，导致后来的人看不懂代码逻辑，改一个 bug 花了三天。你说亏不亏？
规则编号规则：解码 Dir 和 Rule
MISRA C2012 的编号体系，刚开始看会觉得有点乱。其实很简单，就两种前缀：Dir 和 Rule。
- Dir (Directive)： 指导性规则。它不直接对应某一行代码，而是针对开发过程、文档、工具链的要求。比如 Dir 4.1 要求“运行时代码必须可验证”。
- Rule (Rule)： 具体编码规则。它直接约束你怎么写代码。比如 Rule 10.1 要求“操作数不能是布尔类型”。
编号的格式是：Dir X.Y 或 Rule Z.W。X 和 Z 是章节号，Y 和 W 是流水号。比如 Rule 8.2，8 是章节（声明与定义），2 是该章节下的第二条规则。
避坑指南： 我曾经看到有人把 Dir 和 Rule 混为一谈，拿着静态检查工具报的 Dir 违规去改代码，结果发现根本改不了——因为 Dir 不是针对代码的，而是针对流程的。记住：Dir 是“怎么做”，Rule 是“写成什么样”。
规则文档结构解析
MISRA 官方文档里，每一条规则都有一套固定的“八股文”结构。我刚开始看的时候觉得啰嗦，后来才发现，这个结构本身就是一种知识管理的最佳实践。咱们拿一条规则来拆解一下：
Rule 8.2 (Required)
函数标识符的类型应与函数定义的类型一致
1. 类别: Required
2. 原理: 避免因声明与定义不一致导致的未定义行为
3. 参考: C99 6.2.7, 6.7.5.3
4. 示例:
// 违规
extern int16_t foo(void);
int32_t foo(void) { return 0; }
// 合规
extern int16_t foo(void);
int16_t foo(void) { return 0; }
5. 偏差: 无
6. 检查: 静态分析你看，这个结构包含了：
- 类别： 告诉你这条规则是强制、必要还是建议。
- 原理： 解释为什么要有这条规则。这个很重要，理解了原理你才能灵活运用。
- 参考： 指向 C 语言标准的具体条款。MISRA 不是凭空造出来的，它是对 C 标准的“安全增强”。
- 示例： 违规和合规的代码对比。这是最实用的部分。
- 偏差： 是否允许申请偏差。如果是“无”，那就别想了。
- 检查： 用什么方法检查。大部分是静态分析，少数需要代码评审。
我的习惯： 在项目里推行 MISRA 时，我会要求团队成员重点看“原理”和“示例”这两块。原理让你知其所以然，示例让你知道怎么写才对。至于“参考”部分，那是给专家看的，一般开发人员不用深究。
核心规则体系全景图
下面这张图，是我自己总结的 MISRA C2012 规则体系框架。你可以把它当作一张地图，以后遇到具体规则，先想想它在哪个位置。
这张图把咱们刚才讲的内容串起来了。从上到下，先看分类（强制/必要/建议），再看编号类型（Dir/Rule），然后看每条规则的文档结构，最后落到项目里怎么检查。你以后在项目里看到一条 MISRA 违规，先想想它在图里的哪个位置，处理起来就有头绪了。