2. MISRA C:2012 规则体系总览
各位工程师朋友，欢迎来到第二章。上一章我们聊了MISRA C的来龙去脉，这一章咱们直接切入核心——规则体系到底长什么样？
说实话，我第一次翻开MISRA C:2012文档时，也被那几百条规则吓了一跳。但后来我发现，只要理解了它的分类逻辑，这东西其实挺清晰的。就像整理工具箱，你得先知道螺丝刀和扳手分别放在哪个抽屉里。
核心要点：MISRA C:2012 的规则体系由三个维度构成——规则分类（强制/必要/建议）、规则编号（Dir/Rule）、规则覆盖范围（语言子集/编码风格/静态分析）。理解这三个维度，你就掌握了整个体系的骨架。
2.1 规则分类：强制、必要、建议
MISRA C:2012 把规则分成三个等级。这个分级直接决定了你在项目中必须怎么对待它们。
| 分类 | 英文术语 | 合规要求 | 我的经验 |
|---|---|---|---|
| 强制 | Mandatory | 必须遵守，无例外 | 这是红线，踩了就违规 |
| 必要 | Required | 必须遵守，可申请偏差 | 大部分规则属于此类 |
| 建议 | Advisory | 建议遵守，可不执行 | 我建议你尽量都做 |
强制规则（Mandatory）——这是最严格的等级。说白了，没有任何商量余地。比如 Rule 1.1 要求所有代码必须符合C90标准，你敢用C99的//注释？直接违规。
我在项目中遇到过一家供应商，他们觉得强制规则太死板，偷偷用了几个C99特性。结果客户审计时被抓了个正着，整个交付延期两周整改。嗯，从那以后我再也不敢对强制规则打折扣了。
必要规则（Required）——这是主体，占了规则总数的绝大部分。它允许你申请偏差（Deviation），但必须有充分的理由和正式的审批流程。我个人习惯是：能不申请偏差就别申请，因为审计时每一条偏差都是被重点审查的对象。
建议规则（Advisory）——这类规则不强制，但我建议你尽量遵守。为什么？因为很多建议规则其实是安全经验的总结。你想想看，如果一条规则被写进MISRA，它背后大概率是有血泪教训的。
我的建议：对于建议规则，团队可以设定一个内部目标——比如覆盖率达到90%以上。这样既不会因为追求100%而过度消耗资源，又能保证代码质量。
2.2 规则编号规则：Dir 与 Rule
MISRA C:2012 的编号体系很有意思。它用两种前缀来区分不同类型的规则：Dir 和 Rule。
| 前缀 | 全称 | 含义 | 示例 |
|---|---|---|---|
| Dir | Directive | 指导性规则，偏重过程 | Dir 1.1（合规性文档要求） |
| Rule | Rule | 具体规则，偏重代码 | Rule 1.1（C90标准约束） |
Dir（Directive）——这类规则不直接检查代码，而是关注开发过程和文档。比如 Dir 1.1 要求你必须有一个合规性声明，说明你的项目遵循了哪些规则、哪些地方申请了偏差。我曾经帮一个团队做合规性审计，他们代码写得挺好，但Dir 1.1的文档完全空白。结果审计结论是「不合规」——就因为缺了这份文档。
Rule（Rule）——这才是我们平时说的「规则」。每条Rule都对应一个具体的代码检查项。比如 Rule 8.2 要求函数声明必须有完整的参数类型信息。这类规则可以直接用静态分析工具自动检查。
编号中的数字也有讲究。第一个数字是章节号，第二个数字是流水号。比如 Rule 8.2，8代表第8章（声明相关），2代表该章的第2条规则。这个结构让你能快速定位规则所属的领域。
注意：Dir 和 Rule 的合规性要求不同。Dir 通常需要人工审核文档和流程，而 Rule 可以通过静态分析工具自动检查。别指望用工具自动搞定所有 Dir 规则。
2.3 规则覆盖范围：语言子集、编码风格、静态分析
MISRA C:2012 的规则覆盖了三个层面。理解这个分类，能帮你更好地组织合规性工作。
语言子集（Language Subset）——这部分规则定义了C语言中哪些特性可以用、哪些不能用。说白了，MISRA C 不是教你写C语言，而是告诉你C语言里哪些是坑、得绕着走。比如禁止使用setjmp/longjmp（Rule 21.1），因为这东西会破坏控制流，让代码变得难以预测。
编码风格（Coding Style）——这类规则关注代码的可读性和可维护性。比如命名规范、缩进风格、注释要求等。有人觉得风格问题不重要，但我在项目里吃过亏——一个团队用了三种不同的命名风格，结果代码审查时一半时间在争论「这个变量该叫啥」。后来我们统一按MISRA的风格规则来，争论立刻少了。
静态分析（Static Analysis）——这部分规则需要借助工具来检查。比如数据流分析、控制流分析、指针分析等。Rule 17.1 要求所有函数必须有明确的入口和出口，这靠人眼检查几乎不可能，必须用工具。
实战建议：在项目启动阶段，先确定你的工具链能覆盖哪些规则。比如PC-Lint、Coverity、QAC这些主流工具对Rule的覆盖率通常在90%以上，但对Dir的覆盖率可能只有50%。剩下的部分需要人工审查来补充。
2.4 规则数量与分布
MISRA C:2012 总共有多少条规则？我直接给你数据：
| 类型 | 强制 | 必要 | 建议 | 合计 |
|---|---|---|---|---|
| Dir | 0 | 16 | 0 | 16 |
| Rule | 14 | 101 | 20 | 135 |
| 合计 | 14 | 117 | 20 | 151 |
你看，必要规则占了绝大多数（117条）。这意味着大部分规则都有回旋余地——你可以申请偏差，但得有正当理由。强制规则只有14条，但每一条都是硬骨头。
我记得第一次带团队做MISRA合规时，大家看到151条规则都慌了。后来我们按优先级分批处理：先搞定14条强制规则，再处理117条必要规则，最后看时间精力覆盖建议规则。这样分步走，压力小了很多。
小技巧：把规则按「影响编译/不影响编译」再分一组。强制规则通常会影响编译（比如语法错误），而建议规则通常只是警告。这样你在修复时可以优先处理编译错误，再处理警告。
2.5 规则之间的依赖关系
规则不是孤立的。有些规则之间存在依赖关系——违反了一条，可能连带违反另一条。比如：
- Rule 8.2（函数声明必须有完整参数类型）和 Rule 17.1（函数必须有明确入口和出口）经常一起出现。函数声明不完整，静态分析工具就无法准确判断控制流。
- Rule 10.1（禁止隐式类型转换）和 Rule 10.3（赋值操作中类型必须匹配）本质上是同一个问题的不同角度。
我在项目中遇到过这种情况：修复了一条Rule 10.1的违规，结果触发了三条新的Rule 10.3违规。为什么？因为原来的隐式转换被改成显式转换后，类型匹配关系变了。所以修复规则时，一定要做回归检查。
避坑指南：我曾经一次性提交了50条规则修复，结果CI跑出来120条新违规。从那以后，我每次只修复一个规则类别，跑一遍静态分析，确认没有引入新问题，再继续下一个类别。
2.6 如何快速上手规则体系
说了这么多，你可能觉得信息量有点大。没关系，我给你一个三步走的建议：
- 先读目录——打开MISRA C:2012文档，只看目录。了解16个章节分别讲什么。这花不了半小时，但能让你建立全局观。
- 标记强制规则——把14条强制规则全部标记出来。这些是你的「必做题」。
- 对照工具报告——用静态分析工具跑一遍现有代码，看看哪些规则被触发了。从高频违规开始修复，效率最高。
我个人习惯是把规则编号贴在工位旁边。刚开始记不住，看多了自然就熟了。你想想看，151条规则，每天记5条，一个月就差不多了。