QAC规则配置要怎么设置，QAC规则配置和项目编码规范要怎么匹配，这类问题在嵌入式C/C++开发项目中经常出现；很多团队最开始只想着把MISRA检查运行起来，等到真正接入工具之后才发现，并不是把所有规则全部打开就可以完成设置。QAC常被用于C/C++代码的静态检测、缺陷排查和编码标准合规校验，在安全关键软件、车载软件这类项目中应用较多，规则配置如果和项目编码规范不相匹配，扫描结果就难以发挥实际作用，开发人员也容易将这款工具视为额外的工作负担。

　　一、QAC规则配置怎么设置

　　在设置QAC的规则配置时，不要一开始就追求一次性启用全部规则；不同项目的语言版本、编译器类型、目标运行平台、历史代码存量都存在差异，规则开启得过多过严，告警数量会很快失去控制，规则开启得太少，又无法起到约束代码的作用。相对稳妥的处理方式，是先明确项目实际需要遵循的标准，再确定规则集的启用范围。

　　1、先确定规则基线

　　项目团队首先要明确所采用的规则类别，例如MISRA C、MISRA C++、CERT、CWE，或是企业内部的编码规范；QAC可用于MISRA等编码标准的检查工作，也支持规则处理与合规报告等相关场景，因此项目中最好将规则的来源标注清楚。如果是开发时间较长的存量项目，不建议直接按照最高要求全量启用规则，可以先运行一次基线扫描，查看问题主要集中在哪些模块，再确定哪些规则必须立刻执行，哪些规则先保留观察，哪些历史遗留问题需要分阶段进行治理。

　　2、配置编译环境

　　在【Project Configuration】界面中，要把编译器、宏定义、头文件路径、源文件目录这类信息配置准确；这一步的作用经常被低估，QAC并不是简单按照文本内容扫描代码，它需要尽可能还原项目的真实编译环境。

　　缺少对应的宏定义，条件编译部分就可能出现分析错误，头文件路径设置有误，类型与函数的声明也会随之出现偏差；如果扫描结果中出现大量解析异常，先不要急于修改代码，大多时候需要回头检查工程配置是否正确。

　　3、设置消息等级

　　QAC的规则通常会输出不同类型、不同严重程度的提示消息，项目可以根据风险等级，将这些消息划分为必须修改、需要评审、允许偏离、暂不处理四个类别。不要要求开发人员立刻清理所有消息，否则团队很快会被格式类、风格类的问题占用大量精力；真正需要优先处理的内容，通常是未定义行为、指针风险、数组越界、类型转换、初始化与资源使用相关的问题。

　　二、QAC规则配置和项目编码规范怎么匹配

　　QAC的规则配置与项目的编码规范，要能够相互对应说明；编码规范中写明禁止使用复杂宏，但工具中对应的规则没有开启，后续评审就只能依靠人工检查，大量规则问题被工具扫描出来，编码规范中却没有对应的要求，开发人员也会觉得这些要求十分突兀。两者的制定最好不要相互脱节、各自为政。

　　1、建立规则映射关系

　　可以围绕【项目编码规范条款】与QAC规则编号的对应关系建立映射表，确认每一条规范是否有对应的工具检查提供支撑。

　　并不是每一条规范都能依靠工具自动检查，部分设计约束、命名设计意图、模块边界要求，仍然需要依靠人工评审完成。但可以自动检查的部分，要尽量交由QAC完成，例如类型转换、表达式副作用、指针使用、不可达代码这类问题，人工长期检查不仅工作量大，也容易出现遗漏。

　　2、处理规范和工具差异

　　部分企业的内部规范比MISRA标准的要求更加严格，也有部分内容会因为历史平台、编译器的限制而保留例外情况；这种情况下不要强行修改规则名称，而是要将两者的差异标注清楚。例如某条规则项目暂时不予启用，具体原因是什么，某类告警允许偏离标准，需要经过怎样的审批流程，部分模块因为安全等级更高，规则要求要更加严格，这些内容都要有明确的统一标准。

　　3、不要让规则配置变成个人习惯

　　规则配置最好由项目组、质量人员、安全人员共同确认，不要由单个开发人员随意修改；今天在这个分支关闭一条规则，明天给那个模块添加一个排除目录，时间久了不同环境的扫描结果就无法对应统一。尤其是在多分支、多供应商协同开发的场景下，规则包、配置文件与扫描命令都要进行受控管理。

　　三、QAC规则落地时还要注意什么

　　规则真正落地应用之后，常见的问题通常不在于能不能正常扫描，而在于扫描出的问题要如何处理；如果没有配套的处理流程，开发人员只会看到一堆告警无从下手，如果流程设置得过于繁琐，又会拖慢整体的开发节奏。

　　1、先管新增问题

　　存量老项目可以先冻结历史告警的基线，重点拦截新增代码带来的问题；新增代码不允许继续引入严重的规则违反问题，修改旧代码时可以顺带清理相关的告警。这样不会在一开始就给团队造成过大的压力，也能逐步提升代码的整体质量。

　　2、保留偏离记录

　　在QAC的扫描结果中，并不是所有告警都必须进行修改；部分规则可能与硬件寄存器访问、底层驱动、编译器扩展相关，需要保留对应的偏离说明。关键在于偏离理由不能只标注项目需要，要说明对应的风险、具体理由、适用范围与审批结论。

　　3、接入评审和流水线

　　规则配置稳定之后，可以将QAC扫描接入代码评审或者CI流程中；不要只在交付前运行一次扫描，那时候告警都堆积在一起，修复起来会十分被动。在日常开发阶段就先拦截高风险问题，后续制作合规报告时才不用临时补充相关内容。

　　总结

　　关于QAC规则配置的设置方法，以及规则配置与项目编码规范的匹配方式，核心并不是开启的规则越多越好，而是要让规则真正服务于项目的质量提升。先确定规则基线，再配置准确的编译环境与消息等级，再将企业编码规范与QAC规则做好映射，明确哪些内容由工具自动检查，哪些内容依靠人工评审，哪些情况允许偏离标准；按照这种方式配置出的QAC扫描结果，开发人员能够看懂，质量人员也能够跟进落地，不会变成一份只有在交付前才会翻看的形式化文件。