2. MISRA C2012 核心规则分类：必需、强制、建议的区别与权重
MISRA C:2012 一共定义了 143 条规则。但说实话，刚接触的人一看这个数字，头都大了。我当年第一次拿到文档，翻了几页就合上了——太多了，根本记不住。
后来我才明白，MISRA 自己也没指望你每条都背下来。它把规则分成了三个等级：必需（Required）、强制（Mandatory）、建议（Advisory）。这三个词看着差不多，但实际分量天差地别。
你想想看，如果所有规则都一视同仁，那项目里肯定会出现「为了合规而合规」的敷衍做法。MISRA 用这个分级体系，就是想告诉你：哪些是底线，哪些是红线，哪些是加分项。
2.1 三个等级的定义与权重
先看一张表，把核心区别说清楚。
| 等级 | 英文原名 | 违反后果 | 偏差申请 | 典型数量 |
|---|---|---|---|---|
| 强制 | Mandatory | 必须零违反 | 原则上不允许 | 约 20 条 |
| 必需 | Required | 必须合规，但可申请偏差 | 需书面审批 | 约 100 条 |
| 建议 | Advisory | 建议遵守，不强制 | 无需申请 | 约 23 条 |
嗯，这里要注意：强制规则是绝对不能碰的红线。我在一个汽车电子项目里见过，因为一条强制规则没通过，整个版本的合规报告直接被审计打回。那感觉，真叫一个酸爽。
必需规则是主体。你大部分时间都在跟它们打交道。如果确实有技术原因需要违反，可以走偏差流程——但必须书面说明理由，并且经过技术负责人和架构师签字。我个人习惯是，能不走偏差就不走，因为审计的时候每一条偏差都会被反复盘问。
建议规则嘛，说白了就是「最好这样做」。不遵守不会导致合规失败，但遵守了能让代码质量上一个台阶。我曾经在一个项目里把所有建议规则都关了，结果后期测试发现好几个潜在的整数溢出——后来一查，全是建议规则能提前发现的。
2.2 强制规则：没有商量余地
强制规则数量不多，但每一条都是血的教训换来的。比如：
- Rule 1.1：所有代码必须遵守 ISO C 标准。这条看着像废话，但我在项目中见过有人用编译器扩展写汇编内联，结果换了个编译器直接编译不过。
- Rule 2.1：不得出现不可达代码。你以为没人会写？我见过一个团队在 if-else 里把两个条件写成了互斥但逻辑上永远走不到 else 分支，结果那个 else 分支里藏着一段关键的错误处理。
- Rule 14.1：循环必须是有界的。嵌入式系统里死循环是灾难，尤其是看门狗没喂的情况下。
我曾经在一个安全关键项目里，因为赶工期，对一条强制规则（Rule 8.2：函数必须有显式原型）睁一只眼闭一只眼。结果集成测试时，一个函数因为隐式声明被编译器当成了 int 返回，实际返回的是指针——直接导致内存访问越界。从那以后，我再也不敢在强制规则上打折扣。
2.3 必需规则：合规检查的主战场
必需规则占了 MISRA C:2012 的大头，大约 100 条。它们覆盖了：
- 声明与定义：比如 Rule 8.4（外部链接的标识符必须显式声明）、Rule 8.7（函数和对象不应在不需要外部链接时定义为外部链接）
- 表达式与赋值：比如 Rule 10.1（不得对基本类型进行非法的隐式转换）、Rule 12.1（运算符优先级必须明确）
- 控制流：比如 Rule 15.5（switch 语句的每个 case 都必须以 break 或 return 结束）
- 指针与内存：比如 Rule 18.1（不得对指针进行算术运算，除非指向数组元素）
这些规则，每条都可以申请偏差。但申请偏差不是写一句话就行的。我见过最规范的偏差申请单，里面包含了：违反的规则编号、违反的代码位置、违反的技术原因、替代方案分析、风险评估、审批人签字。一套流程走下来，比直接改代码还费时间。
对于必需规则，我的策略是「先全开，再逐条评估」。第一次跑静态分析时，把所有必需规则都打开。然后看报告，把那些确实无法避免的违反，集中走一次偏差审批。这样既保证了合规性，又不会因为频繁申请偏差而拖慢进度。
2.4 建议规则：锦上添花还是雪中送炭？
建议规则经常被忽视。很多团队在配置工具时直接把它们关了，理由是「反正不强制」。但我觉得，这个做法有点可惜。
举个例子：Rule 0.1（建议规则）要求代码必须符合编译器的实现定义行为。这条看着不起眼，但如果你在代码里依赖了某个编译器的特定行为（比如 char 是有符号还是无符号），换一个编译器就可能出问题。我有个朋友的项目，从 GCC 换到 IAR，结果 char 的符号性变了，整个通信协议的解码全乱套。
再比如 Rule 4.1（建议规则）要求不得使用八进制常量。你可能觉得「谁会写八进制啊？」——但 C 语言里 int x = 010; 是合法的，而且值是 8 不是 10。这种坑，静态分析工具能帮你提前揪出来。
所以我的态度是：建议规则能开就开。它们不会让你的合规报告变红，但能让你的代码更健壮。
2.5 三者的权重关系：一张图看懂
下面这张图，是我自己总结的「MISRA 规则权重金字塔」。你可以把它当作项目里分配精力的参考。
2.6 实际项目中的权重分配策略
说了这么多理论，那在实际项目里到底怎么分配精力？我根据自己的经验，列了一个优先级清单：
- 第一优先级：强制规则——配置工具时直接设为 Error 级别，违反就编译不过。没有任何商量余地。
- 第二优先级：必需规则——设为 Warning 级别，但必须全部审查。每条违反都要有对应的偏差记录或修复记录。
- 第三优先级：建议规则——设为 Info 级别，作为代码评审的参考。不强制修复，但建议团队在代码评审时讨论。
强制规则是「法律」，必需规则是「规章」，建议规则是「指南」。
法律不能违反，规章可以申请豁免但要有正当理由，指南最好遵守但不必强求。
最后说一句：MISRA 的分级不是用来给你偷懒的。我见过有人把必需规则全关了，只留强制规则，然后宣称「项目符合 MISRA」。这种做法，说白了就是自欺欺人。审计的人一眼就能看出来——因为合规报告里会列出每条规则的检查状态。
嗯，关于规则分类就讲到这里。记住这个金字塔结构，后面配置工具的时候，你会知道每条规则该设成什么级别。