用於生產項目的代碼度量標準（C＃，Visual Studio）的常用值

Question

這裏有關於代碼度量標準的一些問題，尤其是有關目標值的this one。我在尋找的是現實生活中的「平常」項目。也許這只是我自己，但是我從來沒有做過的項目都考慮到了這些因素，所以當我運行ReSharper Code Issues或Visual Studio Code Metrics時，似乎我是第一個 - 所以這些值總讓我感到驚訝。從我目前的SharePoint任務

例子：

Maintainability | Cyclomatic cmplx. | Inher. depth | Class coupl. | LOC 
67    | 6,712    | 7   | 569   | 21,649 
68    | 3,192    | 7   | 442   | 11,873 

更新：所以現在的問題是，你通常會看到什麼樣的價值觀「在野外」？拋開最佳值和最佳做法，通常會遇到什麼值？

Answer 1

我假設這些值是彙編級別。如果是這樣，環複雜度和代碼行對方法級別最有幫助。 繼承深度應該主要在課堂上進行考察。 類別耦合在首先查看方法級別，然後再查看課程級別時會給出更有用的反饋。

除了提供指引stack overflow link您所包含的代碼完成第二版有這樣說的方法圈複雜，頁458：

• 0-5例行可能是罰款。
• 6-10開始思考如何簡化日常工作。
• 10+打破常規的一部分進入第二個程序，並從第一常規

在「現實生活」項目稱呼它，什麼是可以接受可能會取決於你是開發過程的類型使用。如果團隊正在實踐TDD（測試驅動開發）並努力編寫代碼，那麼這些指標應接近最優值。

如果TAD（測試後開發），或者甚至更多，沒有單元測試的代碼，那麼期望所有度量都高於最優值，因爲可能有更多的耦合，更復雜的方法和類，或許更多多產的遺傳可能會升高。不管怎樣開發代碼，目標應該是限制「壞」指標的情況。

Answer 2

有關軟件度量標準的根本誤解是，它們在放入漂亮報告時非常有用。

大多數人使用下列缺陷的過程：

• 收集任何度量他們的工具支持
• 編寫一份報告
• 比較它針對的推薦值
• 開始狩獵了問題，他們的新發現答案可能地址

這是錯誤的，倒退和反作用在如此多的層面上，它甚至不好笑。任何度量收集的正確方法是首先計算出爲什麼。你測量的原因是什麼？與回答你可能找出測量並給予你知道什麼你爲什麼和什麼你能弄清楚如何向獲得可能引導進一步詢問一些信息。

我已經看到了您列出的指標的各種價值觀，並且在項目或環境中誠實地進行比較，但實際上這些比較並沒有多大意義。

你可以相當肯定地說，同一個團隊將產生看起來像他們以前做的東西。但是你不需要指標就能搞清楚。

您可以使用度量標準來查找「熱點」進行調查，但是如果您有質量問題，無論如何，問題模塊中的bug都會聚集在一起，並且爲它們尋找它們大多是無用的。

現在不要誤解我的意思。我喜歡指標。我已經寫了多個腳本&工具來提取可視化，並與他們做各種花哨的東西，這一切都很好玩&甚至可能是有益的，但我並不是所有這些後來確定。