规则分类与解读：必需、强制、建议的区别与落地策略

MISRA C:2012 一共定义了 143 条规则。刚接触的人一看，头就大了。其实没那么复杂，这些规则分成了三个等级：必需（Required）、强制（Mandatory）、建议（Advisory）。理解它们的区别，是落地 MISRA 的第一步。

我见过不少团队，一上来就把所有规则都打开，结果编译报错几百条，开发人员直接崩溃。说白了，你得知道哪些是必须守死的，哪些是可以商量的。

三种规则的核心差异

先看一张对比表，把三者的区别说清楚。

规则等级	英文原名	合规要求	违反后果	典型场景
强制	Mandatory	必须遵守，无例外	违反即不合规，无法通过评审	未定义行为、内存安全
必需	Required	必须遵守，但可申请偏差	需书面说明理由并获批准	代码风格、命名规范
建议	Advisory	推荐遵守，不强制	可忽略，但建议尽量遵循	可读性、可维护性

强制规则（Mandatory）—— 没有商量余地

强制规则是 MISRA 里最硬的一类。违反它，意味着代码存在确定性风险。编译器、静态分析工具必须报错，评审时必须否决。

我记得有一次，团队里一个新同事写了一段代码：

int *p = NULL;
*p = 42;  // 违反强制规则

这种对空指针的解引用，就是典型的强制规则违规。没有任何理由可以绕过它。你想想看，在安全关键系统里，这种代码一旦跑起来，后果是什么？

强制规则通常涉及：

• 未定义行为（如数组越界、除零）
• 内存安全（空指针、野指针）
• 类型违规（隐式转换导致数据丢失）
• 控制流异常（死循环、不可达代码）

必需规则（Required）—— 常态下的铁律

必需规则是 MISRA 里数量最多的一类。它不像强制规则那样绝对，但也不是可以随便绕过的。合规要求是：要么遵守，要么申请偏差。

偏差（Deviation）是什么？就是书面说明你为什么违反这条规则，以及为什么这样做是安全的。偏差需要经过技术负责人、安全工程师甚至客户的审批。

举个例子，规则 8.2（必需）要求函数参数必须显式声明类型。但如果你在维护一个老项目，里面大量使用了 K&R 风格的函数声明，怎么办？

// 违反必需规则 8.2
int foo(x, y)
int x;
int y;
{
    return x + y;
}

这时候，你可以申请偏差，说明这是遗留代码，短期内无法重构，但已经通过单元测试覆盖。偏差被批准后，这条违规就可以暂时放行。

我个人习惯把必需规则分成两类：

• 可快速修复的：比如缺少花括号、未使用的变量。这类直接改代码，不需要偏差。
• 需要偏差的：比如为了性能使用特定编译器扩展。这类必须走偏差流程。

建议规则（Advisory）—— 锦上添花

建议规则是最容易被忽视的。很多团队直接把它们关掉，理由是“反正不强制”。但我觉得，这样做有点可惜。

建议规则虽然不强制，但它们往往指向代码的可读性、可维护性和长期质量。比如规则 4.1（建议）要求不要使用八进制常量。你可能会说：“我从来不用八进制，这条规则对我没用。” 但你想过没有，如果团队里有人不小心写了个 0123，他以为这是十进制 123，实际上编译器把它当成八进制 83。这种 bug 很难查。

我处理建议规则的方式是：

• 在静态分析工具里开启所有建议规则
• 把违规标记为“警告”而非“错误”
• 在代码评审时，如果看到建议规则违规，顺手改掉
• 不强制要求，但鼓励团队尽量遵守

说白了，建议规则是帮你养成好习惯的。你不遵守，代码也能跑。但长期来看，遵守建议规则的项目，bug 率更低，维护成本也更低。

落地策略：分阶段、分优先级

讲完了三种规则的区别，接下来聊聊怎么落地。我总结了一个三步走的策略：

1. 第一阶段：清零强制规则
   • 配置静态分析工具，强制规则违规直接报错
   • 不允许任何强制规则违规进入代码库
   • CI/CD 流水线中，强制规则违规阻断构建
2. 第二阶段：管理必需规则
   • 建立偏差申请模板和审批流程
   • 对可自动修复的违规，配置自动格式化工具
   • 每周评审偏差清单，控制偏差数量
3. 第三阶段：优化建议规则
   • 开启所有建议规则，但不阻断构建
   • 在代码评审中鼓励修复建议规则违规
   • 每季度统计建议规则违规趋势，持续改进

知识体系图：规则分类与落地流程

下面这张图展示了三种规则的关系，以及从违规到合规的完整流程。

这张图把整个流程串起来了。从规则分类开始，到处理方式，再到分阶段落地。你可以把它贴在团队的白板上，每次讨论 MISRA 合规时，看一眼就知道当前在哪个阶段。

常见问题与避坑

最后，分享几个我在项目中遇到的常见问题：

• 问题：静态分析工具把建议规则报成错误，导致构建失败。
  解决：检查工具配置，建议规则应设为警告级别，不影响构建。
• 问题：偏差申请流程太复杂，开发人员干脆不申请，直接绕过。
  解决：简化偏差模板，控制在 5 行以内。审批流程不超过 2 个工作日。
• 问题：团队对强制规则和必需规则的理解不一致。
  解决：做一次全员培训，用实际代码案例演示两者的区别。我每次培训都会拿一个真实的 bug 案例来讲，效果比讲理论好得多。