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，然后繼續下一步。注意做如此判斷的人則需要擁有項目的管理員權限。