一次MISRA扫描产生上百条告警，开发人员修改后重新扫描，数量确实减少了，但哪些问题已经修好、哪些只是被过滤掉，未必能从汇总数字中看出来。等到版本交付时再补查，往往还要翻提交记录、找旧报告。比较省事的做法，是从发现问题时就保留身份信息，让修改、复查和关闭记录始终围绕同一项问题展开。

嵌入式项目开发过程中，宏定义几乎无法完全避免。硬件寄存器配置、编译选项控制、固定参数管理等场景都会使用宏。不过，宏和普通变量、函数不同，它是在预处理阶段完成替换，代码正式编译前已经改变了原始结构。开发人员看到的宏名称，和编译器最终处理的内容可能并不一致。项目进行MISRA C检查时，一些看似正常的代码，经过宏展开后可能出现类型转换、表达式计算异常等问题。因此，宏使用需要提前规划，出现违规时也需要结合展开结果进行分析。

在嵌入式软件开发中，类型转换属于非常常见的代码行为。变量计算、接口调用、数据存储时，都可能出现不同数据类型之间的转换。C语言为了提高开发灵活性，允许编译器自动完成部分类型转换，但这种自动处理也可能带来一些隐藏问题。例如整数长度变化导致数据丢失，有符号和无符号数据比较出现异常，浮点计算结果产生偏差等。对于汽车电子、控制器软件等长期运行的项目，这类问题通常需要在编码阶段提前发现。MISRA C通过一系列规则限制隐式类型转换，帮助开发人员减少类型使用不明确带来的风险。

switch在状态机、通信协议解析和模式选择中使用频率很高，同时也是MISRA C重点约束的控制结构之一。进行“MISRA C对switch语句有哪些要求，MISRA C switch语句缺少default如何处理”时，应关注分支结构是否清晰、异常输入是否有处理路径，以及整改后是否仍存在控制流隐患。以下主要按照MISRA C:2012的Rule 16.x规则说明。

在TESSY中，测试对象的创建与识别不完整的排查，重点在于让TESSY获得完整的待测源码和编译环境，再通过模块分析将可测试的函数识别出来。当测试对象没有完整显示时，问题通常并不在于测试用例本身，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，与正式工程没有保持一致。排查时应当先查看分析日志，再去检查预处理之后的源码内容。

在TESSY中，测试对象的创建与识别不完整的排查，重点在于让TESSY获得完整的待测源码和编译环境，再通过模块分析将可测试的函数识别出来。当测试对象没有完整显示时，问题通常并不在于测试用例本身，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，与正式工程没有保持一致。排查时应当先查看分析日志，再去检查预处理之后的源码内容。

MISRA合规证据应该留到什么程度MISRA合规审查通常先看哪些材料，许多做嵌入式软件的项目全都绕不开这些事。要把MISRA合规这件事办好，并不是光把静态扫描的工具拽过来跑上一遍就行了，也更不能只把违规的条数清到零就算交了差。真正应该留下来的那些证据，是要能说清楚项目到底用了哪一个版本的规矩，查过了哪些代码段落，中间翻出来了哪些毛病，这些毛病里又有哪些已经被修掉了，哪些是经过偏离那一套审批之后特意保留下来的。在MISRA Compliance:2020这份东西里面，它特别点明了，等项目跑到收尾的时候，是该攒出来一份合规方面的汇总材料，用它去记下项目在最后被声明出来的那个合规程度。

怎样安排MISRA培训才会更有效果，以及团队在落地时常遇到的阻力该怎么去化解，这个问题不能只是被理解成给开发人员上一堂规则课。很多项目组在做MISRA培训的时候，会讲上一大堆规则编号，也讲了很多专门的概念，可开发人员回到工程里面，还是不清楚该怎么去改代码，也不清楚哪些问题是必须处理的，更不清楚例外的说明要怎样去写，要让MISRA真正落到工程里面，培训就要把代码、工具、问题单还有评审资料放在一起讲，项目组也要提前把阻力化解掉，像开发人员会感觉规则拖慢了进度，工程负责人会觉得流程变重了，供应商会觉得要求不够清晰，如果培训安排得明白，落地时遇到的阻力也处理得及时，MISRA才不会一直停留在工具报告和文档要求里面。

开发人员不要只从名称上去理解这两套规则，它们虽然都面向C语言，也都可以帮助减少代码里的毛病，但处理问题的侧重点并不同。MISRA C会把注意力更多地放在代码写法是不是稳定、能不能被工具查出来，以及后期评审时团队能不能讲明白；CERT C则更关心代码会不会留下安全方面的隐患，比如内存使用越过了边界、整数计算结果溢出、资源用完后没有被释放、来自外部的数据没有做检查，这些都属于CERT C经常要查看的内容。项目团队可以把MISRA C当作基础的写法要求，再把CERT C看成安全问题的补充检查，这样在安排规则时方向会清楚一些。

很多人一提到MISRA C，第一反应就是“把所有规则背下来”。可真到项目里，最容易出错的地方反而不是记不住编号，而是把规则内容、规则级别和项目执行要求混成了一件事。MISRA官方在《MISRA Compliance:2020》里把这件事讲得很清楚：每条guideline都会带一个MISRA category，也就是Mandatory、Required或Advisory，这个级别决定的不是规则“重不重要”这么简单，而是违反之后在合规上能不能被接受、要不要走正式偏离流程。