Sonar平台中项目主要指标以及代码坏味道详解

Sonar平台中项⽬主要指标以及代码坏味道详解原⽂链接：
Sonar项⽬主要指标以及代码坏味道详解
，
1、Reliability可靠性
1.1 Reliability Rating
可靠性⽐率的计算⽅法）
A = 0 Bug 最⾼等级A，表⽰代码⽆bug
B = at least 1 Minor Bug 代码只要有⼀个次要bug，等级就为B
C = at least 1 Major Bug 只要包含⼀个重要bug，等级将为C
D = at least 1 Critical Bug 只要有⼀个严重bug，等级评估为D
E = at least 1 Blocker Bug 只要有⼀个最⾼等级的阻断级别的bug，可靠性评估为E，最低级别。

1.2 Reliability remediation effort
修复所有缺陷问题成本/耗时
1.3 Reliability remediation effort on new code
在新增代码上修复所有缺陷问题成本/耗时
1.4 备注
图中⽓泡⼤⼩根据bug数变化，bug数越⼤⽓泡越⼤。

视觉更加直观。

2、Security安全性
2.1 Security Rating
安全度指标计算⽅法
A = 0 Vulnerability 没有漏洞时，项⽬评估为最⾼级别A
B = at least 1 Minor Vulnerability 只要包含⼀个次要漏洞，项⽬评估为级别B
C = at least 1 Major Vulnerability 只要包含⼀个重要漏洞，项⽬评估为级别C
D = at least 1 Critical Vulnerability 只要包含⼀个严重漏洞，评估为D
E = at least 1 Blocker Vulnerability 只要包含⼀个阻断漏洞，项⽬评估为最低级别E
2.2 备注
lines of code 计量⽅法：包括⾄少⼀个字符，不包括空格。

图中⽓泡⼤⼩根据漏洞数变化，漏洞数越⼤⽓泡越⼤。

视觉上直观显⽰。

3、Maintainability可维护性
3.1 Technical Debt
“技术债务”概念，这个概念最早是在 1992 年由 Ward Cunningham 在他的论⽂“The WyCash Portfolio Management System”中提出的，之后被软件⼯程界接受并推⼴，《重构》的作者 Martin Fowler 也在其⽹站上对技术债务有所介绍。

其实原理可以理解为“出来混早晚要还的”，当前不规范的代码，会对以后产品修改的成本造成影响。

Technical Debt 计算公式如下：
3.2 开发成本
开发⼀⾏代码（LOC）的成本。

⽰例：如果开发1 LOC的成本估计为30分钟，则此属性的值为30。

⽬前我们采⽤的是系统默认值30。

注意此处成本是指从零开始重写代码所需的成本。

3.3 可维护性
可维护性等级范围从A（⾮常好）到E（⾮常差）。

评级由技术债务⽐率的值决定，技术债务⽐率是将项⽬的技术债务与从零开始重写代码所需的成本进⾏⽐较。

A到D的默认值为0.05,0.1,0.2,0.5。

任何超过0.5评级就为E。

举个例⼦：假设开发成本是30分钟，2,500 LOC的技术债务为24,000分钟的项⽬将有技术债务⽐率为24000 /（30 * 2,500）= 0.32。

因此项⽬的可维护性评级就是D。

4、Coverage覆盖率
4.1 Coverage
⾏覆盖和条件覆盖的混合。

单元测试覆盖多少源代码。

Coverage = (CT + CF + LC)/(2*B + EL)，其中：CT = conditions that have been evaluated to ‘true’ at least once⾄少有⼀次被判断为true的条件数
CF = conditions that have been evaluated to ‘false’ at least once ⾄少⼀次被判断为false的条件数
LC = covered lines = lines_to_cover uncovered_lines 已覆盖的⾏数
B = total number of conditions 条件总数
EL = total number of executable lines (lines_to_cover) 所有可执⾏的代码总⾏数
4.2 Line coverage
单元测试覆盖⾏数密度
Line coverage = LC / EL
LC = covered lines (lines_to_cover - uncovered_lines) 已覆盖的⾏数
EL = total number of executable lines (lines_to_cover) 所有可执⾏的代码总⾏数
4.3 Condition coverage
Condition Coverage=（CT+CF）/(2*B)
CT = ⾄少⼀次使⽤ ‘true’的条件数
CF = ⾄少⼀次使⽤ ‘false’ 的条件数
B = 条件总数
4.4 Unit test success density (%)
测试成功密度=（单元测试总数-（单元测试错误数+单元测试失败数））/单元测试数*100
5、Duplications重复
5.1 Duplication
SonarQube使⽤⾃⼰的复制/粘贴检测引擎，可以检测重复：
1、在源⽂件中
2、跨项⽬中的多个⽂件
3、项⽬的各个模块
4、跨多个项⽬
5.2 Duplicated Lines(%)
重复率=重复⾏数/总⾏数*100
Duplicated blocks:重复代码块⾏数
Duplicated files:重复⽂件数
Duplicated lines:重复⾏数
5.3处理Duplicated
a、分析这些重复，并通过使⽤继承或其他合适的模式来消除它们（只有在要对块进⾏单元测试时才这样做）
b、将复制的更改复制到复制的块上
c、使⽤问题和技术债务机制，通过编辑质量配置⽂件以包括来⾃公共Sonar存储库的复制块规则，监控成本并跟踪此错误的修复。

6、Size⼤⼩
7、Complexity复杂度
7.1 Complexity复杂度
以下关键词增加复杂性：if, for, while, case, catch, throw, return (不是⽅法的最后⼀个语句), &&, ||, ?
7.2 备注
else, default, finally不增加复杂度
代码复杂度过⾼将难以理解、难以维护。

8、Code Smells坏味道
Code Smell
某些东西会混淆维护者或在读代码时产⽣误导。

有时，Bug和Code Smell之间的界线是模糊的。

当有疑问时，问⾃⼰：“打破这条规则的代码是否是程序员想要的？如果答案是“可能不是”，那么它是⼀个Bug。

否则它就是⼀个代码坏味道。

9、Issues问题
9.1 Open Issues
当前存在的全部问题
9.2 Reopened Issues
关闭后⼜重新打开的问题，可能由于之前误判关闭或者重新出现同样问题，需要再次将问题置为打开状态。

9.3 Confirmed Issues
确认的问题 - 通过确认问题，你基本上是承认：“是的，这是⼀个问题。

” ，并将问题从“打开”状态移动到“已确认”状态。

9.4 False Positive Issues
误判问题-在上下⽂中查看问题，你意识到可能由于⼀些原因判定了这个问题，然⽽这个问题实际上不是⼀个问题，因此可以在此处标记为False Positive，然后继续下⼀步。

注意：做此判断的⼈需要拥有项⽬的管理员权限。

9.5 Won't Fix
不修复的问题 – 通过查看上下⽂中的关联，你意识到虽然这是⼀个有效的问题，实际上并不需要修复。

因此可以在此处标记为Won't Fix，然后继续下⼀步。

注意做如此判断的⼈则需要拥有项⽬的管理员权限。