1. Sourc Lines of Code (SLOC)

統計代碼行數可能是最簡單的方法。它能體現軟件的規模，為項目的發展和計劃提供一些數據支撐。例如，我們每個月統計一次代碼的行數，我們就能大體知道項目的發展情況。當然，這不是一個值得信賴的標準，因為有重構以及設計的因素。

SLOC ***是統計 Source Logical Line of Code (SLLOC) 以獲得更準確的信息。Logical code lines 不包含空行，單個括號行以及注釋行。你可以通過 Metrics 這樣的工具很容易的統計 SLLOC。

代碼行數不應該被用來衡量開發效率。否則容易造成重復的，不易維護的和不專業的代碼。

2. Bugs per code_section/module/time_period

問題跟蹤是保證測試和可維護性的關鍵步驟。假如所有的問題（bug）都是有跟蹤的話，每個代碼單元，每個模塊或者某個特定時間（day, week, month...）的問題就很容易被統計（例如 Mantis 工具）。當我們有了這些數據以后，問題的根源就可以被盡早發現并處理。

問題數量可以作為衡量開發質量的一個標準，但必須用的很小心。假如過分強調 bug 數量，那么開發和測試的關鍵就會很緊張。在一個有效率的公司，所有的員工都應該融洽的相處。

為了更好的對代碼質量進行評估。Bug 可以分為 low, medium, high 三種級別，因為它們的重要性和修復的成本是不一樣的。

3. Code Coverage

Code coverage 表明了代碼被測試的程度。有很多工具可以自動統計這個數據，例如 Cobertura 。

Code coverage 不能說明單元測試的整體質量，但是能說明測試的覆蓋面。它可以和其他一些指標一起用來衡量軟件的質量。當然，我們也需要經常回顧單元測試代碼和集成測試的用例。

4. Design/Development Contraints

軟件開發中有很多設計規則，例如： 

• 類/方法的長度 
• 方法/屬性的數量 
• 方法的參數數量 
• 特殊數值以及字符串的使用量 
• 注釋的比例

這些規則都是保證代碼可讀性和可維護性的重要指標。開發團隊應該選擇一些或者全部的規則來實施（例如 maven pmd plugin ）。這將幫助提高軟件產品的質量。

5. Cyclomatic Complexity（環路復雜度）

把環路復雜度單獨列出來講是因為它和其他的設計準側不太一樣。環路復雜度是關于代碼實現和執行。它也可以通過工具自動計算，例如 pmd 。

這個數值是獨立的代碼執行路徑數量。例如： 

Cyclomatic Complexity = E(edges) - N(nodes) + 2P (exit nodes)   
So, Cyc.Cmp. = 8 - 7 + 2*1 = 3  

你也可以看到，從起點到終點，有三條不同的路徑。這個值往往是針對方法來計算。根據不同的項目類型，我們可以設定這個值的上限，例如6,8，或者10。

一個指標不能說明整個項目的質量。使用更多的指標，會讓你對項目的質量有更全面的了解。

原文鏈接，OSChina.NET 編譯