程式碼度量 - 循環複雜度

當使用程式碼度量時，最不被理解的項目之一似乎是循環複雜度。 從本質上講，對於循環複雜度，數字越低越好。 可以使用循環複雜度來瞭解任何指定程式碼的測試、維護或疑難排解的難度，以及程式碼產生錯誤的可能性。 在高層級上，我們透過計算原始程式碼中所做決策的數量來確定循環複雜度的值。 在本文中，您將從簡單的循環複雜度範例開始，以快速了解這個概念，然後查看一些關於實際使用和建議限制的其他資訊。 最後，有引文區段可以用來挖掘此主題更深入的資料。

範例

循環複雜度定義為測量「原始程式碼函式中決策邏輯的數量」NIST235。 簡單地說，必須在程式碼中做出的決策越多，它就越複雜。

我們要了解它是如何運作的。 建立新的主控台應用程式，並透過前往 [分析>計算解決方案之程式碼度量] 立即計算程式碼度量。

請注意，循環複雜度為 2 (可能是最低值)。 如果新增非決策程式碼，請注意複雜度沒有變更：

如果新增決策，循環複雜度值將新增 1：

當您將 if 陳述式變更為 switch 陳述式，然後要做出 4 個決策時，它將從原來的 2 變為 6：

讓我們來看 (假設的) 更大的程式碼基底。

請注意，當向下切入至 Products_Related 類別時，大多數項目的值為 1，但也有幾個項目的複雜度為 5。 就其本身而言，這可能不是什麼大不了的事，但考慮到大多數其他成員在同一類別中都有 1，應該仔細查看這兩個項目，看看其中有什麼。 您可以透過以滑鼠右鍵按一下項目並從捷徑功能表中選擇 [移至原始程式碼] 來執行此動作。 請仔細查看 Product.set(Product)：

指定所有 if 陳述式，您可以看到為什麼循環複雜度為 5。 在這一點上，您可能會决定這是可接受的複雜度等級，或者可能會進行重構以降低複雜度。

魔術數字

與此產業的許多計量一樣，沒有適用於所有組織的精確循環複雜度限制。 然而，NIST235 確實指示，10 的限制是很好的起點：

「然而，用作為限制的確切數字仍然存在一些爭議。 McCabe 最初提出的 10 的限制有重要的支援證據，但高達 15 的限制也被成功使用。 與一般專案相比，具有幾個作業優勢的專案應保留超過 10 的限制，例如經驗豐富的員工、正式設計、新式程式設計語言、結構化程式設計、程式碼逐步解說和全面的測試計劃。 換句話說，組織可以挑選大於 10 的複雜度限制，但前提是它確信自己知道自己在做什麼，並願意投入更複雜模組所需的額外測試工作。」NIST235

循環複雜度與行號

僅僅看程式碼數本身，充其量是程式碼品質的非常廣泛的預測因素。 函式中的程式碼越多，出錯的可能性就越大，這一觀點有一定的基本道理。 然而，當您將循環複雜度與程式碼相結合時，您就可以更清楚地了解潜在的錯誤。

如由 Software Assurance Technology Center (SATC) 於 NASA 所述：

「SATC 發現，最有效的評估是規模和 (循環) 複雜度的結合。 具有高複雜度和大尺寸的模組往往具有最低的可靠性。 尺寸小、複雜度高的模組也存在可靠性風險，因為它們往往是非常簡短的程式碼，很難變更或修改。」SATC

程式碼分析

程式碼分析包含可維護性規則的類別。 如需詳細資訊，請參閱可維護性規則。 使用舊版程式碼分析時，延伸設計指導方針規則集包含可維護性區域：

可維護性區域內是複雜度的規則：

當循環複雜度達到 25 時，此規則會發出警告，因此其有助於您避免過度複雜。 若要深入了解規則，請參閱 CA1502

整體回顧

最重要的是，高複雜度表示隨著維護和疑難排解時間的增長，發生錯誤的可能性更大。 仔細觀察任何具有高複雜度的函式，並决定是否應該對其進行重構以降低複雜度。

引用

MCCABE5

McCabe, T. 和 A. Watson (1994)，軟體複雜度 (雜談：防護軟體工程日誌)。

NIST235

Watson, A. H. 和 McCabe, T. J. (1996 年)。 結構化測試：使用循環複雜度計量的測試方法 (NIST 特刊 500-235)。 2011 年 5 月 14 日擷取自 McCabe 軟體網站：http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J。(1998)。 軟體計量與可靠性 (IEEE 軟體可靠性工程國際研討會論文集)。 2011 年 5 月 14 日擷取自賓夕法尼亞州立大學網站：https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159