コード メトリックを使用する場合、最も理解されていない項目の 1 つは、サイクロマティックな複雑さであるようです。 基本的に、サイクロマティック複雑度では、数値が大きいほど悪く、数値が小さい方が良いです。 サイクロマティックな複雑さを使用して、特定のコードがテスト、保守、またはトラブルシューティングをどの程度難しいかを把握したり、コードがエラーを生成する可能性を示したりすることができます。 大まかに言うと、サイクロマティック複雑さの値は、ソース コードで行われた決定の数をカウントすることによって決定されます。 この記事では、概念をすばやく理解するためのサイクロマティック複雑さの簡単な例から始めて、実際の使用状況と推奨される制限に関する追加情報を確認します。 最後に、この主題をさらに詳しく調べるために使用できる引用文献のセクションがあります。
例
サイクロマティックな複雑さは、"ソース コード関数における決定ロジックの量" NIST235測定と定義されます。 簡単に言えば、コードで行う必要がある決定が多いほど、複雑になります。
実際の動作を見てみましょう。 新しいコンソール アプリケーションを作成し、[分析] > [ソリューションのコード メトリックスを計算] に移動して、コード メトリックをただちに計算します。
サイクロマティック複雑度が 2 (可能な限り低い値) であることに注意してください。 非決定コードを追加する場合は、複雑さが変わらないことに注意してください。
決定を追加すると、サイクロマティックな複雑さの値が 1 つ上がります。
if ステートメントを switch ステートメントに変更し、4 つの決定を行うと、元の 2 から 6 に変わります。
(仮定的な) 大規模なコード ベースを見てみましょう。
Products_Related クラスにドリルダウンする場合、ほとんどの項目の値は 1 ですが、そのうちの 2 つの項目は複雑さが 5 であることに注意してください。 この違いは大したことではないかもしれませんが、他のほとんどのメンバーが同じクラスに 1 つを持っていることを考えると、間違いなくこれら 2 つの項目を詳しく見て、その中の内容を確認する必要があります。 項目を右クリックし、コンテキスト メニューから [ソース コードに移動] 選択すると、詳細を確認できます。 Product.set(Product)を詳しく見てみましょう。
すべての if ステートメントを考えると、サイクロマティックの複雑さが 5 である理由がわかります。 この時点で、この結果が許容される複雑さのレベルであると判断したり、リファクタリングして複雑さを軽減したりできます。
マジックナンバー
この業界の多くのメトリックと同様に、すべての組織に適合する正確なサイクロマティック複雑さの制限はありません。 ただし、NIST235 は、10 の制限が適切な開始点であることを示しています。
「ただし、制限として使用する正確な数は、いくぶん議論の余地があります。 McCabe によって提案された 10 の元の制限には重要な支持証拠がありますが、15 の上限も正常に使用されています。 経験豊富なスタッフ、正式な設計、最新のプログラミング言語、構造化プログラミング、コードチュートリアル、包括的なテスト計画など、一般的なプロジェクトよりもいくつかの運用上の利点があるプロジェクトには、10 を超える制限を確保する必要があります。 言い換えると、組織は 10 を超える複雑さの制限を選択できますが、それが何を行っているかを確実に把握し、より複雑なモジュールに必要な追加のテスト作業に専念する必要がある場合に限ります。」 NIST235
サイクロマティック複雑度と行番号
コードの行数を単独で見るだけで、コード品質の非常に広範な予測器になります。 関数内のコード行が多いほど、エラーが発生する可能性が高くなるという考え方には、いくつかの基本的な真実があります。 ただし、サイクロマティックな複雑さをコード行と組み合わせると、エラーの可能性をより明確に把握できます。
NASA のソフトウェア アシュアランス テクノロジ センター (SATC) の説明に従って、次の手順を実行します。
「SATCは、サイズと(サイクロマティック)複雑さの組み合わせが最も効果的な評価であることを発見しました。 複雑度が高く、サイズが大きいモジュールは信頼性が最も低い傾向があります。 サイズが小さく複雑さが高いモジュールは、変更や変更が困難な非常に簡潔なコードになる傾向があるため、信頼性のリスクでもあります」SATC
コード分析
コード分析には、保守容易性ルールのカテゴリが含まれます。 詳細については、「保守容易性ルール を参照してください。 従来のコード分析を使用する場合、拡張設計ガイドライン規則セットには保守容易性領域が含まれます。
保守容易性領域内には、複雑さのルールがあります。
サイクロマティック複雑さの保守容易性ルール
このルールは、サイクロマティック複雑度が 25 に達すると警告を発行するため、過度の複雑さを回避するのに役立ちます。 規則の詳細については、CA1502 参照してください。
すべてをまとめる
要するに、複雑度が高い数値は、エラーの確率が高くなり、維持とトラブルシューティングの時間が長くなることです。 複雑さが高い関数を詳しく見て、それらを複雑にしないようにリファクタリングする必要があるかどうかを判断します。
引用
MCCABE5
McCabe、T.、A. Watson (1994 年)、ソフトウェアの複雑さ (CrossTalk: 防衛ソフトウェア エンジニアリングのジャーナル)。
NIST235
ワトソン,A. H., & McCabe, T. J. (1996). 構造化テスト: サイクロマティック複雑度メトリックを使用したテスト手法 (NIST Special Publication 500-235)。 2011 年 5 月 14 日、McCabe Software Web サイトから取得: http://www.mccabe.com/pdf/mccabe-nist235r.pdf
SATC（セックス・アンド・ザ・シティ）
ローゼンバーグ、L.、ハンマー、T.、ショー、J. (1998)。 ソフトウェアのメトリックと信頼性 (ソフトウェア信頼性エンジニアリングに関する IEEE 国際シンポジウムの議事録)。 2011年5月14日、ペン州立大学のウェブサイトから取得: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159