程式代碼計量 - 旋式複雜度
當使用程式碼度量時，其中一個最不瞭解的概念似乎是環路複雜度。 基本上，使用旋形複雜度，較高的數位是壞的，而較低的數位是好的。 您可以使用環路複雜度來理解任何給定程式碼的測試、維護或疑難排解的難易程度，並了解程式碼出現錯誤的可能性。 概括而言，我們透過計算原始程式碼中所做的決策數目來判斷循環複雜度的值。 在本文中，您會從一個簡單的旋式複雜度範例開始快速瞭解概念，然後查看一些有關實際使用方式和建議限制的其他資訊。 最後，有一部分引文可用來深入探討此主題。
例
旋式複雜度定義為測量「原始程式碼函式中的決策邏輯數量」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