QAC项目启用的规则一多，检查结果很容易混在一起。安全类、可靠性类和团队自定义规范全放在同一层，开发人员看报告时很难判断先处理哪一批。

　　处理“QAC编码规则怎么分组QAC编码规则分组后检查范围怎么确认”，先要分清两件事：规则分组负责整理诊断结果，项目文件范围决定哪些代码会被分析。两者有关联，但并不是同一个设置。

　　一、QAC编码规则怎么分组

　　QAC通过规则配置文件RCF，把分析器产生的诊断消息映射到具体编码规则。打开规则配置后，可以看到由规则组、子组和规则组成的树形结构，最底层规则再关联实际诊断消息。

　　1、先选择合适的规则配置文件

　　①打开目标QAC项目。

　　②进入【项目】→【项目属性】。

　　③找到【规则配置文件】。

　　④选择需要使用的RCF文件。

　　⑤保存设置并重新分析项目。

　　QAC自带的默认RCF包含完整消息集；critbug配置偏向旧代码中的高风险问题；security配置则缩小到安全相关缺陷。项目已经有明确检查目标时，没必要上来就把所有规则全开。

　　如果项目同时分析C和C++代码，规则结果通常会按语言分开显示。别把C规则组里的数量直接拿去和C++组比较，两边使用的分析组件和消息映射并不一样。

　　2、创建自定义规则组

　　团队可以按项目阶段或问题类型建立自己的层级，例如“必须修复”“发布前处理”“安全检查”和“代码风格”。

　　①打开【项目属性】→【规则配置】。

　　②在【规则】面板中右击语言组件。

　　③选择【新建规则组】并填写名称。

　　④右击新规则组，选择【新建规则】。

　　⑤填写规则编号、名称和说明。

　　⑥右击规则，选择【消息】并关联诊断消息。

　　⑦保存规则配置。

　　QAC允许在规则树的任意层级创建新规则，也可以从空白配置开始搭建完整的自定义层级。创建完成后，配置会保存在当前项目配置中，还可以导出为新的RCF文件。

　　分组别做得太碎。一条规则建一层文件夹，看起来很细，实际展开半天还找不到结果。通常按编码标准、风险级别或团队职责分到两三层就够了。

　　3、导入其他项目的规则分组

　　①进入【项目属性】→【规则配置】。

　　②点击【导入】。

　　③选择需要使用的.rcf文件。

　　④根据情况选择【替换】、【更新】或【合并】。

　　⑤检查规则树后再保存。

　　【替换】会用新文件取代现有配置；【更新】会替换已有组件的映射；【合并】会保留双方规则集，并在冲突时使用导入文件中的值。已经做过大量自定义分组时，直接点【替换】很容易把原来的内容覆盖掉。

　　二、QAC编码规则分组后检查范围怎么确认

　　规则分组只决定诊断消息归到哪里，并不会自动限定源码目录。真正参与检查的文件，仍由QAC项目中的文件列表、同步结果和本次分析方式决定。

　　1、先看项目里包含哪些文件

　　①切换到【文件】面板。

　　②展开项目根目录和源码目录。

　　③检查目标文件是否已经加入项目。

　　④查看第三方代码、生成代码是否被误加。

　　⑤需要时重新同步项目。

　　QAC项目可以手动添加文件，也可以通过构建观察、编译数据库或其他同步方式提取源码、头文件路径和宏定义。文件根本没有进入项目，再完整的规则分组也检查不到。

　　文件列表和实际编译范围不一致时，先修同步配置。别为了让结果数量对上，直接去改规则组，那是在处理另一个问题。

　　2、确认执行的是全项目还是选中文件分析

　　在【文件】面板中选择一个目录，会同时选中该目录及其子目录中的文件。右击后可以只分析选中的文件，也可以从主菜单执行整个项目分析。

　　①清除原来的文件选择。

　　②选择项目根目录，检查是否覆盖全部源码。

　　③执行完整分析。

　　④再单独选择某个模块运行分析。

　　⑤比较两次结果中的文件范围。

　　命令行分析也是同一个逻辑。qacli analyze没有指定文件列表时，会分析项目中的全部文件；使用--files后，则只处理文件清单中的对象。

　　3、从规则组反查实际命中的文件

　　①完成分析后打开【规则组】面板。

　　②展开目标规则组和子规则。

　　③右击需要核对的规则。

　　④选择【仅显示】。

　　⑤在【分析结果/诊断】中查看文件路径。

　　【仅显示】只是过滤当前结果，让面板只保留对应规则或消息，并不会重新改变分析范围。检查结束后，可以右击规则组选择【重置过滤器】，恢复全部结果。

　　这个方法很适合确认某个安全规则到底扫到了哪些模块。比起盯着总数量猜，直接看文件路径更快。

　　三、规则分组后的结果数量为什么对不上

　　规则树里的数量不一定等于诊断列表的简单相加。看到上下级数字不一致，先检查统计方式和抑制状态，不要马上认定配置丢了。

　　1、同一诊断可能对应多条规则

　　一条诊断消息可能同时用于执行多条编码规则。QAC在父级规则组汇总时，只统计唯一诊断，不会因为它属于两个子规则就重复计算。

　　所以两个子组各有10条，父组不一定显示20条。里面有重复诊断时，父级数量会更少，这属于正常统计。

　　2、活动数量与总数量不同

　　【活动】和【总计】出现差异，通常和诊断抑制或基线抑制有关。被抑制的问题仍可能保留在总计中，但不会作为当前活动问题显示。

　　①打开【分析结果/诊断】。

　　②检查是否启用了基线。

　　③查看是否存在注释、Pragma或Dashboard抑制。

　　④临时显示被抑制诊断。

　　⑤再核对规则组数量。

　　别看到活动数量减少就以为规则没跑。有时规则照常执行，只是结果被基线隐藏了。

　　3、规则被禁用或消息没有关联

　　禁用规则后，诊断消息不再映射到该规则。重新分析时，该规则不会继续出现在规则组树中，相应数量也会减少。

　　可以回到【规则配置】，展开目标规则，确认规则处于启用状态，并检查底层是否还关联诊断消息。

　　只建了规则名称，却忘了关联消息，树形结构看着挺完整，实际一条结果也不会进来。

　　4、当前项目配置选错

　　QAC项目可以包含多套配置。不同配置可能使用不同RCF、分析组件、编译器模板和文件参数。切换到另一套配置后，规则组和检查结果都会变化。

　　核对时要同时记录项目名称、当前配置、RCF文件和分析时间。只说“同一个项目结果不一样”，信息还不够，可能两次用的根本不是同一套配置。

　　总结

　　“QAC编码规则怎么分组QAC编码规则分组后检查范围怎么确认”关系到检查结果能否被团队准确理解和使用。清楚的规则层级可以降低报告阅读成本，稳定的文件范围和项目配置则能保证不同分析结果具备可比性。分组完成后，重点不是追求规则数量越多越好，而是让规则、源码范围和统计口径始终对应。希望本文对大家整理QAC编码规则和核对检查结果有所帮助。