私が時々目にする用語は「循環的複雑度」です。ここで、「言語XのCCを計算する方法」または「最小量のCCでYを実行する方法」についていくつか質問がありましたが、それが何であるかがよくわかりません。
NDependのWebサイトで、基本的に「メソッド内の決定の数。if、for、&&などのそれぞれがCCの「スコア」に+1を追加する）という説明を見ました。それは本当ですか？はいの場合、なぜですか？これは悪いですか？コードを理解しやすくするために、ifステートメントの数をかなり少なくしたいと思うかもしれませんが、これは本当にすべてですか？
それとも、それにもっと深い概念がありますか？
私はより深い概念を知りません。それは一般的に保守性指数の文脈で考えられていると思います。特定のメソッド内にブランチが多いほど、そのメソッドの操作のメンタルモデルを維持することが難しくなります（一般的に）。
循環的複雑度が高いメソッドも、単体テストで完全なコードカバレッジを取得するのがより困難です。（ Mark Wに感謝します！）
もちろん、それは保守性の他のすべての側面をもたらします。エラー/リグレッションなどの可能性。ただし、コアコンセプトは非常に単純です。
循環的複雑度は、ブロックを通過するすべてのパスを実行するために、さまざまなパラメーターを使用してコードのブロックを実行する必要がある回数を測定します。カウントを大きくすると、論理エラーがテスト戦略から逃れる可能性が高くなるため、悪い結果になります。
Cyclocmatic complexity = Number of decision points + 1
決定ポイントは、if、if…else、switch、for loop、whileloopなどの条件ステートメントである可能性があります。
次の表は、アプリケーションのタイプを示しています。
循環的複雑度は1〜10にあります通常のアプリケーションと見なされます
循環的複雑度は11〜20にあります中程度のアプリケーション
循環的複雑度は21〜50にあります危険なアプリケーション
循環的複雑度は50以上あります不安定なアプリケーション
うん、それは本当にそれです。コードがとることができる実行パスが多いほど、テストする必要のあるものが多くなり、エラーが発生する可能性が高くなります。
私が聞いたもう一つの興味深い点：
インデントが最大のコード内の場所は、CCが最大である必要があります。これらは、読み取り/保守が困難になることが予想されるため、一般に、テストカバレッジを確保するための最も重要な領域です。他の回答が指摘しているように、これらはカバレッジを確保するためのコードのより難しい領域でもあります。
循環的複雑度は本当に恐ろしい流行語です。実際、これはソフトウェア開発で使用されるコードの複雑さの尺度であり、コードのより複雑な部分を指摘します（バグがある可能性が高いため、非常に注意深く徹底的にテストする必要があります）。E-N + 2Pの式を使用して計算できますが、プラグインによって自動的に計算されることをお勧めします。コードの可読性と保守性を維持するために、CCを5未満に保つように努力する必要があるという経験則を聞いたことがあります。
私は最近、JavaプロジェクトでEclipse Metricsプラグインを試しました。これには、通常のEclipseヘルプと統合される非常に優れた簡潔なヘルプファイルがあり、さまざまな複雑さの測定値とヒントとコツの定義をさらに読むことができます。コードの改善について。
これまでに提供された回答は、ソフトウェア品質と循環的複雑度との相関関係については言及していません。研究によると、循環的複雑度の測定基準を低くすると、より高品質のソフトウェアを開発するのに役立つはずです。これは、読みやすさ、保守性、および移植性のソフトウェア品質属性に役立ちます。一般に、5〜10の循環的複雑度のメトリックを取得するように試みる必要があります。
循環的複雑度などの指標を使用する理由の1つは、一般に、人間は脳内で同時に約7（プラスまたはマイナス2）の情報しか追跡できないためです。したがって、ソフトウェアが複数の決定パスで過度に複雑である場合、ソフトウェアがどのように動作するかを視覚化できる可能性は低くなります（つまり、循環的複雑度のメトリックが高くなります）。これは、エラーのあるソフトウェアやバグの多いソフトウェアの開発につながる可能性があります。これについての詳細は、こことウィキペディアで見つけることができます。
つまり、CCが低いメソッドでは、フォークやループなどが少なくなり、メソッドがより複雑になるという考え方です。アナライザーを使用して500,000行のコードを確認し、CCが大幅に高いいくつかのメソッドを確認することを想像してみてください。これにより、理解を深めるためにこれらのメソッドのリファクタリングに集中できます（CCが高いとバグ率が高くなることもよくあります）
ルーチンの各決定ポイント（ループ、スイッチ、ifなど）は、基本的に同等のifステートメントに要約されます。それぞれについて、if取得できる2つのコードパスがあります。したがって、最初のブランチには2つのコードパスがあり、2番目のブランチには4つの可能なパスがあり、3番目のブランチには8つのパスがあります。少なくとも2**Nのコードパスがあります。ここで、Nはブランチの数です。
これにより、コードの動作を理解し、Nがいくつかの小さな数を超えたときにコードをテストすることが困難になります。
循環的複雑度は、制御フローグラフを使用して計算されます。プログラムのソースコードを通る線形独立パスの定量的測定の数は、循環的複雑度と呼ばれます（if / if else / for / while）
そういうことです。ただし、「case」または「switch」ステートメントの各ブランチは1としてカウントされる傾向があります。実際、これはCCがcaseステートメント、およびそれらを必要とするすべてのコード（コマンドプロセッサー、ステートマシンなど）を嫌うことを意味します。
関数の制御フローグラフを検討してください。出口から入口まで追加のエッジが実行されています。循環的複雑度は、グラフを2つに分割せずに作成できるカットの最大数です。
例えば：
function F:
if condition1:
...
else:
...
if condition2:
...
else:
...
リンクされたグラフの循環的複雑度が3である理由は、おそらく直感的に理解できます。
Cyclomatricの複雑さは、基本的に、保守性のためにより多くの注意を必要とするコードの領域を把握するためのメトリックです。基本的にはリファクタリングへの入力になります。深いネストされたループや条件などを回避するという観点から、コードの改善領域を確実に示します。
Cyclomatricの複雑さは、ソフトウェアのユニットがどれほど複雑であるかを示す尺度です。これは、プログラムが条件付き論理構造（if、while、for、switch＆casesなど）でたどる可能性のあるさまざまなパスの数を測定します。あなたがそれを計算することについてもっと学びたいならば、ここであなたが見ることができる素晴らしいユーチューブビデオですhttps://www.youtube.com/watch?v=PlCGomvu-NM
プログラムがとることができるさまざまなパスまたはシナリオを明らかにするため、テストケースを設計する際に重要です。「優れたテスト容易性と保守性を実現するために、McCabeは、プログラムモジュールが循環的複雑度10を超えないようにすることを推奨しています」（Marsic、2012、p.232）。
参照：Marsic。、I.（2012年9月）。ソフトウェア工学。ラトガース大学。www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdfから取得
