在嵌入式项目开发中，代码检查通常会伴随整个开发周期进行。对于采用C/C++语言的项目，开发人员经常需要根据MISRA规范检查代码是否存在不符合要求的写法。使用QAC执行MISRA检查时，除了关注检测出的违规项，还需要确认规则配置和分析环境是否符合项目实际情况。有些项目在首次检查时结果正常，但调整规则或者更换代码版本后，报告内容可能出现变化，这时就需要结合QAC配置和检查结果进一步分析原因。

在进行C/C++代码质量检查时，分析环境配置是QAC项目建立过程中的基础环节。QAC需要根据项目实际开发环境获取编译参数、代码路径以及编译器信息，才能正确理解源码结构并执行静态分析。实际使用过程中，很多检查失败并不是代码本身导致，而是分析环境没有正确配置，例如编译选项缺失、头文件路径错误、目标编译器设置不匹配等。因此，在创建QAC分析项目时，需要先还原项目真实编译环境，再根据检查结果进行调整。

QAC进行静态分析时，并不是直接读取开发人员看到的源代码，而是先经过预处理阶段，再对展开后的代码进行规则检查。因此，项目中的宏定义、条件编译以及头文件依赖都会直接影响最终分析结果。如果QAC使用的预处理环境与实际编译环境不一致，就可能出现代码分支判断错误、类型无法识别、函数声明缺失等问题。处理“QAC怎么设置预处理器宏，QAC预处理器宏未正确展开如何检查”时，重点是让QAC使用的宏配置与编译器实际参数保持一致，而不是单纯为了减少告警随意增加宏。

QAC项目启用的规则一多，检查结果很容易混在一起。安全类、可靠性类和团队自定义规范全放在同一层，开发人员看报告时很难判断先处理哪一批。处理“QAC编码规则怎么分组QAC编码规则分组后检查范围怎么确认”，先要分清两件事：规则分组负责整理诊断结果，项目文件范围决定哪些代码会被分析。两者有关联，但并不是同一个设置。

在嵌入式软件或大型C、C++项目中，只看单个函数内部的诊断信息，往往难以判断某段代码会被哪些模块调用，也不容易发现递归调用、跨文件依赖和影响范围。QAC可以基于已完成的分析结果生成函数调用与关联信息。了解QAC函数调用图怎么查看QAC函数调用图关系不完整怎么排查，有助于从单个函数继续追踪到整个项目的调用链路。

QAC的增量分析应当怎样配置，以及QAC增量分析的结果不完整又该怎样处理，这是老项目在接入静态分析时很容易碰到的问题。如果每次都跑全量分析，时间会拖得很长，CI流水线也容易被拖慢；但如果只做增量分析，又担心某些受到影响的文件没有被扫描到。QAC的增量分析，更适合用在日常提交、合并请求和分支检查这些场景中，用来尽早地发现新增的问题，但是它不应当完全替代周期性的全量分析。在CI场景下，增量分析通常需要依赖已有的基线，并且着重关注由本次变更所带来的新增问题。

想要搞懂QAC的分析结果怎么看，还有分析结果里的调用路径怎么定位，不能只盯着告警的总数量不放；QAC的静态分析结果，一般会按文件、消息等级、规则组、诊断信息这几个维度来展示，使用的人要先分清问题属于哪种类型，是违反了编码规则，是数据流出了问题，是跨模块带来的问题，还是项目配置不对引发的分析异常。Perforce的QAC官方文档里也写了，在图形界面里，可以通过Files、Message Levels、Rule Groups和Analysis Results/Diagnostics这些面板，来查看完整的分析内容。

在给QAC划定分析范围的时候，关键是要先分清楚，哪些代码是必须要进到规则检查里面去的，又有哪些，只不过是第三方的库、机器自动生成出来的代码、历史归档留下来的东西，或者是临时构建出来的产物，QAC的命令行工具，它可以去分析单个的文件，也可以去分析整个QAC的项目，或者是CMA的项目，在默认的情况下，它只会去把那些发生了变化的文件，还有那些依赖着它们的文件，或者是相关的设置，给重新分析一遍；要是你动手去执行了清理的操作，那它就会把之前分析的结果给删掉，等到下一次再去跑的时候，就会触发一次从头再来的重新分析。

在代码静态分析跑完了以后，有时候会碰到一种情况，就是分析的结果，在工具里面看着倒是挺好的，可一旦到了要拿去交付给评审的时候，光靠那个界面就不太够用了，项目组这边，通常是需要去导出像代码评审报告、MISRA合规报告，还有标准符合性报告，这一类的文件，好把它们交给研发的负责人、质量的团队，或者是客户那边去做审核，QAC它是支持在项目的级别上，去生成报告的，也可以通过命令行的方式，基于项目分析的结果去出报告，这里面，常见的报告类型，就包括CRR、MCR、SCR等等好几种。

在QAC里做规则裁剪，真正要先分清的一件事是，规则本身和消息本身不是一回事。Perforce官方文档写得很清楚，QAC用RCF，也就是Rule Configuration File，来定义分析过程中发现的warning messages和规则之间的映射关系；项目里的Rule Configuration面板会按层级树的方式展示这些规则和子组，选到最底层规则时，才能看到实际关联的enforcement messages。也就是说，所谓“裁剪规则”，本质上不是把分析器关掉，而是在项目层面对哪些消息归入哪些规则、哪些规则纳入当前合规口径做配置。