使用程式碼度量時，其中一個最不瞭解的概念似乎是圈複雜度。 基本上，使用旋形複雜度，較高的數位是壞的，而較低的數位是好的。 您可以使用圈複雜度來瞭解任何給定的程式碼在測試、維護或排除故障方面的困難程度，以及程式碼產生錯誤的可能性指標。 概括而言，我們會計算原始程式碼中所做的決策數目，以判斷旋式複雜度的值。 在本文中，您會從一個簡單的旋式複雜度範例開始快速瞭解概念，然後查看一些有關實際使用方式和建議限制的其他資訊。 最後，有一部分引文可用來深入探討此主題。
例
旋式複雜度定義為測量「原始程式碼函式中的決策邏輯數量」NIST235。 簡單地說，必須在程序代碼中做出的決策越多，就越複雜。
讓我們看看它的運作情形。 建立新的控制台應用程式，然後移至 [分析] > [計算解決方案的程式代碼計量]，立即計算您的程式代碼計量。
請注意，旋形複雜度為 2（可能的最低值）。 如果您新增非決策程序代碼，請注意複雜性不會變更：
如果您新增決策，迴圈複雜度值會上升一個：
當您將 if 語句變更為具有四個決策的 switch 語句時，它會從原始的兩個變成六個：
讓我們看看一個 （假設） 較大的程式代碼基底。
請注意，當您深入至 Products_Related 類別時，大部分項目的數值為 1，但其中幾個項目的複雜度為 5。 就本身來看，這種差異可能並不大，但考慮到大多數其他成員在同一類別中都有一個，您應該仔細查看這兩個專案，並查看其中的內容。 您可以在項目上按下滑鼠右鍵，然後從內容功能表中選擇 [移至原始程式碼]，以便更仔細查看。 請仔細查看 Product.set(Product)：
假設所有的 if 語句，您可以看到旋式複雜度為何為五。 此時，您可能會決定此結果是可接受的複雜度層級，或者您可以重構以降低複雜度。
魔術數字
與這個行業中的許多度量一樣，沒有適用於所有組織的確切圈複雜度限制。 不過，NIST235 確實表示限制為10是不錯的起點：
然而，作為限制使用的精確數位仍然有些爭議。 根據麥卡貝的提議，原定的限額為10，並有顯著的證明作為支持，但上限提高到15也被成功地應用過。 超過 10 項的限制應保留給具有數個作業優勢的專案，例如經驗豐富的員工、正式設計、現代程式設計語言、結構化程式設計、程式代碼逐步解說，以及完整的測試計劃。 換句話說，組織可以挑選大於10的複雜度限制，但前提是它確定它知道它正在做什麼，並且願意投入更複雜的模組所需的額外測試工作。」NIST235
旋式複雜度和行號
僅僅查看程式碼行數本身，充其量是一個非常粗略的程式碼質量預測指標。 有一些基本事實，即函式中的程式代碼行越多，錯誤的可能性就越大。 不過，當您將旋式複雜度與程式代碼行結合時，您就更清楚了解錯誤的可能性。
如美國宇航局軟體保證技術中心（SATC）所述：
“SATC發現最有效的評估是大小和（旋風）複雜性的組合。 具有高複雜度和大型大小的模組通常會具有最低的可靠性。 大小低且複雜度高的模組也是可靠性風險，因為它們往往非常簡潔的程序代碼，這很難變更或修改。」SATC
程序代碼分析
程式代碼分析包含可維護性規則的類別。 如需詳細資訊，請參閱 維護性規則。 使用舊版程式代碼分析時，擴充設計指導方針規則集包含可維護性區域：
在維護性區域內有一個關於複雜度的規則。
此規則會在旋形複雜度達到 25 時發出警告，因此可協助您避免過於複雜。 若要深入了解規則，請參閱 CA1502
整合一切
根本問題是，高複雜度數字意味著隨著時間增加，維護和疑難排解的錯誤機率更高。 進一步瞭解任何具有高度複雜度並決定是否應該重構的函式，使其變得較不複雜。
引文
MCCABE5
麥卡貝，T. 和 A. 沃森（1994年）軟體複雜性（CrossTalk: 國防軟體工程雜誌）。
NIST235
沃森，A.H.，& 麥卡比，T.J.（1996年）。 結構化測試：使用旋形複雜度計量的測試方法（NIST 特殊出版物 500-235）。 從 McCabe Software 網站擷取自 2011 年 5 月 14 日：http://www.mccabe.com/pdf/mccabe-nist235r.pdf
SATC
羅森伯格，哈默，T.，肖，J.（1998年）。 軟體計量和可靠性（IEEE 國際軟體可靠性工程研討會）。 從賓夕法尼亞州立大學網站擷取自 2011 年 5 月 14 日：https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159