大家在用这个工具做静态分析的时候，往往只盯着告警的数量看，代码指标反而被冷落了，其实去看这些指标，还有处理超标的情况，主要不是为了让报告里那些红色的数字消失，而是得去琢磨代码是不是已经变得不好修、不好测、也不好审了；这个工具的分析能力挺多的，像什么基础规则检查、数据流、抽象解释，还有度量指标这些都有，算出来的结果能给代码结构风险当个参考。

　　一、C/C++test代码度量怎么查看

　　这些指标一般呆在静态分析结果里，或者在专门的度量报告里面，它不像语法报错那样直接喊你“这里写错了”，而是拿函数复杂程度、文件大小、模块关联这些数据来提醒作者，以后这部分代码大概会很难改。

　　1、在配置里跑指标检查

　　作者需要进到工具的配置界面，找到度量或者相关标准配置，这里有个小建议，就是先把配置拷贝一份，再根据项目的要求去改限制的数值，别把自带的模版给弄乱了；如果是用命令行来跑，可以用下面这种差不多的写法：

　　cpptestcli

　　-config"builtin://Metrics"

　　-compiler gcc_9-64

　　-input cpptest.bdf

　　-report./report

　　等它扫描完了，把网页或者格式报告打开，就能瞧见具体的数值了，大家经常看的也就是分支复杂度、代码行数、函数长短、路径多少、注释多不多、模块是不是粘在一起这些；新版本里对路径数量这个指标还做过扩展，这就说明在汽车或者嵌入式检查里，这些指标并不是可有可无的赠品。

　　2、在软件界面里找代码

　　如果是用现成的插件，指标要是超标了，一般会当作问题显示在结果列表里，大家可以按照项目、文件或者严重程度来过滤，然后再点进具体的函数位置；这个时候不能光看哪个文件变红了，得看明白到底是函数太绕了，还是文件字数太多，或者是模块之间互相依赖得太厉害。

　　3、去平台看趋势的样子

　　要是项目连了管理平台，大家就能把测试结果传上去，用仪表盘看不同版本的变化，这个平台支持用网页来看报告、过滤和分析，看静态分析、测试跑得怎么样、质量趋势都挺方便的。

　　二、C/C++test代码度量超阈值怎么判断

　　数字超标其实不算最后的结论，它只是在提醒作者这里有维护的风险，在动手改之前，得先看看到底是哪类数据超了，再想想这部分代码是不是现在团队真正需要去伺候的对象。

　　1、分支复杂度超标了

　　这个复杂度要是高了，通常就是说函数里面的判断分支太多了，比如一个函数又要检查参数，又要判断状态，还要算业务、管错误和打日志，那测试用例根本就没办法测全。

　　这种代码可不能为了让数字降下来就瞎拆，比较好办的办法是去找逻辑的底线，看看校验的逻辑能不能单独拿出去，状态变来变去能不能换成表格来弄，重复的判断能不能合在一起，错误处理能不能统一找个出口，等把它拆好了，函数不仅指标能掉下来，读起来和测起来也会轻松一大截。

　　2、函数太长或者文件太大

　　函数要是写得太长，一般就是好几个处理步骤全黏在一起了，文件要是太大了，那就经常是遇到了什么都能管的底层代码，短期内看着集中起来挺省事的，以后要是改一个地方，说不定就会连累一大片。

　　3、粘连和聚拢指标不对劲

　　模块要是跟别的地方牵扯不清，通常就是它要用太多外面的头文件、全局变量或者别的状态，如果聚拢性不好，那就是说一个文件或者类里面塞了太多不相干的杂活。

　　这类问题往往不是改一两行就能应付过去的，大家可以先从头文件包含、全局变量拿取、公共函数多少这几个地方下手，把不该让人看见的状态收回到模块内部，把只给某个功能干活的逻辑从公共工具里剥离出来，这样以后改动的时候，影响的范围才好控制。

　　三、C/C++test代码度量超阈值怎么处理

　　指标超标以后，处理的规矩可以简单记成一句话：新写的代码尽量快点改，老代码挪到后面分段治，外面的和自动生成的代码单独拨到一边，大家可千万别一看到超标就去藏，也别为了能通过检查就直接把标准放得很宽。

　　1、先看看扫描的地方对不对

　　要是把别人的库、供应商的开发包、还有自动生成的代码全算进指标里，报告一下子就被冲乱了，这些代码大多不是团队平时要去伺候的，用一样的标准去管它们，其实没什么意思。

　　大家可以先翻翻第三方、外部、自动生成这些目录是不是需要扔掉，真正值得使劲看的是业务逻辑、协议解析、状态机、驱动适配、跟安全挂钩的模块，还有最近经常被改动的那些代码。

　　2、按照风险大小分批去弄

　　新写的代码要是超标了，建议在大家互相看代码的阶段就把它做掉，比如新加的函数太绕了，说明设计的时候可能还没想明白，等以后更多的东西加进去，就更不好弄了。

　　老代码超标的话，可以分成几批来治，比如先去动经常要改的核心模块，没啥风险又挺稳当的模块先搁在一边，在技术欠账或者质量改进计划里记上一笔就行，至于自动生成的、适配平台的、第三方接口的封装，要是实在没办法改，可以划掉或者写个原因，但是原因不能只写两个字“忽略”。

　　3、实在不行就改改标准，但得有借口

　　这个限制的数值不是死理，底层的驱动、协议的东西、还有上层的业务模块，它们复杂的特点都不太一样，新项目和留下来的老项目也不一定能用同一个门槛，大家把配置拷出来以后，根据团队的规矩设个合适的顶棚就行。

　　总结

　　其实看代码指标还有处理超标，差不多能顺着这个路子来：先去跑指标的测试配置，在报告、软件界面或者管理盘里看看具体的数，然后再琢磨超标的到底是分支、长度、文件大小还是粘连的问题，最后顺着代码的脾气决定是重构、扔掉、写说明还是改标准。