规则分类全景图：强制规则、必要规则、建议规则——哪些必须听，哪些可以商量？
各位工程师朋友，咱们今天聊一个很实际的问题。
MISRA C:2012 一共 143 条规则，拿到手一看，头都大了。是不是每条都得死磕？
说实话，不是。MISRA 自己就把规则分成了三个等级：强制（Mandatory）、必要（Required）、建议（Advisory）。这三个词的分量完全不同。
我见过不少团队，要么把建议规则当耳旁风，结果线上出了诡异 bug；要么把建议规则当圣旨，搞得开发效率直线下降。这两种极端，都不可取。
核心原则：强制规则是底线，必要规则是常态，建议规则是进阶。底线不能碰，常态要遵守，进阶看场景。
一、强制规则（Mandatory）—— 没得商量，必须执行
强制规则一共 16 条。数量不多，但每一条都是血泪教训换来的。
这类规则的特点是：违反它，代码的行为就是未定义的。编译器可以按任何方式解释你的代码，甚至直接忽略它。
举个例子，Rule 1.2：禁止任何未定义行为。听起来像废话对吧？但我在项目中遇到过有人写 i = i++，觉得“反正我测试过了没问题”。结果换了个编译器优化等级，结果完全不一样。这就是未定义行为的典型。
强制规则还有：
- Rule 2.1：项目不得包含不可达代码。
- Rule 3.1：注释不能嵌套。
- Rule 21.1：禁止使用
#define或#undef修改标准库宏。
警告：强制规则没有“商量”的余地。如果你在代码审查中发现违反强制规则，必须立即修复。我曾经见过一个团队因为违反 Rule 1.2，导致安全认证被直接打回，项目延期三个月。
二、必要规则（Required）—— 默认遵守，偏差需审批
必要规则是 MISRA C 的主体，一共 117 条。这是你日常编码中最常打交道的部分。
这类规则的特点是：违反它，代码可能仍然能工作，但存在潜在风险。比如类型转换不当、控制流不清晰、变量作用域过大等。
我个人习惯把必要规则分成两类：
- 可自动检查的：比如 Rule 10.1（操作数类型必须匹配），静态分析工具能直接报出来。
- 需要人工判断的：比如 Rule 8.2（函数必须有原型声明），虽然工具能检查，但有时候为了兼容旧代码，你可能需要申请偏差。
说到偏差（Deviation），这里有个关键点：必要规则允许申请偏差，但必须有书面理由。你不能说“我觉得这样写更简洁”就跳过。我建议的流程是：
- 确认违反规则的原因（性能？兼容性？硬件限制？）
- 评估风险等级（低/中/高）
- 编写偏差文档，由技术负责人和架构师签字
- 在代码中加注释标注偏差编号
| 规则类别 | 数量 | 处理方式 | 典型场景 |
|---|---|---|---|
| 强制（Mandatory） | 16 | 必须遵守，无偏差 | 未定义行为、不可达代码 |
| 必要（Required） | 117 | 默认遵守，可申请偏差 | 类型转换、控制流、命名 |
| 建议（Advisory） | 10 | 推荐遵守，可灵活处理 | 注释风格、代码布局 |
三、建议规则（Advisory）—— 锦上添花，但别忽视
建议规则只有 10 条。很多人觉得“建议嘛，就是可做可不做”。
嗯，这话对了一半。建议规则确实不像强制规则那样有“法律效力”，但它们往往是团队代码风格和可维护性的风向标。
比如 Rule 4.1：字符集必须使用执行环境定义的字符集。这条规则在大多数项目里不会出问题，但如果你做的是国际化产品，或者要移植到不同编码的嵌入式平台，忽略它就会踩坑。
我曾经在一个项目中，团队决定忽略所有建议规则，理由是“加快开发速度”。结果半年后，新来的工程师看不懂代码里的注释风格，维护成本直线上升。最后我们不得不花两周时间统一风格，反而更慢了。
我的建议：建议规则可以作为团队编码规范的基础。如果团队刚接触 MISRA，可以先从强制和必要规则入手，等稳定了再逐步引入建议规则。但不要完全忽略它们——它们的存在是有原因的。
四、规则分类全景图
下面这张图帮你快速理清三类规则的关系和优先级。
五、实战中的处理策略
知道了分类，怎么落地？我分享几个经验：
- 静态分析工具配置：强制规则设为 Error，必要规则设为 Warning，建议规则设为 Info。这样工具会自动帮你分级。
- 代码审查重点：强制规则必须逐条审查，必要规则抽样审查，建议规则只在有时间时看。
- 偏差管理：建立偏差库，记录每条偏差的原因、风险、审批人。我见过一个项目积累了 200 多条偏差，最后审计时全被驳回——因为没有统一管理。
一句话总结：强制规则是法律，必要规则是公司制度，建议规则是团队习惯。法律不能犯，制度要遵守，习惯慢慢养。
好了，规则分类就聊到这里。记住这个全景图，后面我们讲具体调试和故障定位时，你会知道哪些规则是“红线”，哪些是“黄线”，哪些只是“建议线”。