循環的複雑度の範囲[閉じた]

循環的複雑度のカテゴリーは何ですか？例えば：

1-5：維持しやすい
6-10：難しい
11-15：非常に難しい
20+：近づきにくい

何年もの間、私は10が制限であるという仮定を行ってきました。そしてそれ以上のものは悪いです。私は解決策を分析しており、コードの品質を判断しようとしています。確かに循環的な複雑さだけが測定値ではありませんが、それは役立ちます。循環的複雑度が200以上のメソッドがあります。私はそれがひどいことを知っていますが、上の例のように、より低い範囲について知りたいです。

私はこれを見つけました：

カーネギーメロンの前述の参照値は、循環的複雑度値の4つの大まかな範囲を定義しています。

1から10までの方法はシンプルで理解しやすいと考えられます

10から20の間の値は、より複雑なコードを示しますが、依然として理解しやすいかもしれません。ただし、コードが取り得る分岐の数が多いため、テストはより難しくなります。

20以上の値は、非常に多数の潜在的な実行パスを持つ典型的なコードであり、非常に困難かつ労力をかけてのみ完全に把握およびテストできます。

50を超えるなど、さらに高くなるメソッドは確かに維持できません

ソリューションのコードメトリックを実行すると、25未満の場合に結果が緑色で表示されます。これには同意しませんが、他の入力を取得することを望んでいました。

サイクロマティックの複雑性について一般に受け入れられている範囲リストはありますか？

design programming-practices metrics

— ボブ・ホーン
ソース

ソフトウェアエンジニアリングのリーダーとして認識されている組織であるSoftware Engineering Instituteからのデータを見つけました。私はあなたの質問が何であるか理解していません-あなたは循環的複雑さの範囲リストを見つけました。他に何をお探しですか？

— トーマスオーエンズ

さまざまな範囲を見てきました。それはほんの一例です。そして、MSは25未満のすべてに対して「緑色」を表示します。受け入れられる範囲リストが1つあるかどうか疑問に思っていました。おそらくそれを見つけたのでしょう。

— ボブ・ホーン

@ThomasOwensに同意しますが、この質問をしてくれてうれしいです。私は質問と回答の両方としてそれを支持しました。

— エヴォラー

Steve McConnellのCode Completeの第2版では、通常、0〜5の循環的複雑度で問題ないことを推奨していますが、複雑度が6〜10の範囲に入るようになる場合は注意する必要があります。彼はさらに、10の複雑さを超えるものはすべて、コードのリファクタリングを検討する必要があると説明しています。

— GibboK

回答:

それはあなたのプログラミングスタッフの能力に依存しており、マネージャーとしてのあなたの感受性に少なからず影響していると思います。

一部のプログラマーはTDDの熱心な支持者であり、最初に単体テストを作成しないとコードを作成しません。他のプログラマーは、単一の単体テストを作成することなく、完全に優れたバグのないプログラムを作成できます。各グループが許容できる循環的複雑度のレベルは、ほぼ確実に大幅に変化します。

これは主観的な指標です。コードメトリックスソリューションの設定を評価し、適切な結果が得られる快適なスイートスポットに調整します。

— ロバート・ハーベイ
ソース

同意し、さらに、それは複雑さの原因に依存します。ステートマシンなどの一部として他の関数を呼び出す大きなswitchステートメントは、理解するのが実質的に簡単であるにもかかわらず、非常に複雑になる可能性があります。

— -whatsisname

大きなswitchステートメントは、通常、多態性などのOOP原則の欠如を示すものではありませんか？ステートマシンは、OOPまたはデザインパターンを使用して、エレガントな方法で実装できます。いや？

— ボブ・ホーン

「優雅さ」が役立ついくつかの問題については、他の人にとっては物事をより混乱させるだけです。特効薬はありません。

— -whatsisname

-1「他のプログラマーは、単一の単体テストを書くことなく、完全に優れたバグのないプログラムを作成することができます。」バグをテストしていないと、そのバグを知ることができません。

— セバスチャン

@Sebastien：単体テストがないからといって、テストされていないわけではありません。そして、もしあなたが十分であれば、テストや初歩的な煙テストなしでバグのないコードを書くことは絶対に可能です。確かに、それらの人々はまれな品種です。

— ロバートハーベイ

事前定義されたカテゴリはなく、いくつかの理由でカテゴリ化はできません。

いくつかのリファクタリングの技術はちょうど（ないからある地点から別の地点への複雑さを移動し、あなたのコードのフレームワークや十分にテストされた外部ライブラリに、しかし、1つの場所からのコードベースの他に）。循環的な複雑さを軽減し、上司（または絶えず増加するグラフィックスを備えたプレゼンテーションを愛する人）にあなたが何か素晴らしいものを作るのに時間を費やしたことを説得するのに役立ちますが、コードは以前と同じように悪いままです。
反対に、デザインおよびプログラミングパターンを適用してプロジェクトをリファクタリングすると、循環的な複雑さが悪化する場合がありますが、リファクタリングされたコードは明確になることが期待されます：開発者はプログラミングパターンを知っていますそのため、それらのコードは簡素化されますが、循環的な複雑さでは考慮されていません。
リファクタリングを行わない他の手法の中には、循環的な複雑さにまったく影響を与えないものもありますが、開発者にとってはコードの複雑さが大幅に軽減されます。例：関連するコメントまたはドキュメントを追加します。構文糖を使用してコードを「近代化」する。
単純に、循環的複雑さが無関係である場合があります。彼のコメントでwhatsisnameが示した例が好きです：いくつかの大きなswitch文は非常に明確であり、それらをよりOOPyの方法で書き直すことはあまり役に立ちません（そして初心者によるコードの理解を複雑にします）。同時に、これらの声明は、サイクロマティックな複雑さという点で災害です。
ロバート・ハーヴェイがすでに述べたように、それはチーム自身に依存しています。

実際には、良い循環的複雑さを持つソースコードを見てきましたが、それはひどいものでした。同時に、循環的複雑度の高いコードを見てきましたが、それを理解するのに苦労はしませんでした。

ただ、与えられたコードがどれだけ良いか悪いか、維持するのがどれだけ簡単かを完璧に示すツールはなく、ツールもありえないということです。特定の絵は傑作であり、別の絵は芸術的価値がないため捨てる必要があることを伝えるアプリケーションをプログラムすることはできません。

設計によって破損するメトリック（LOCやファイルあたりのコメント数など）があり、いくつかの生のヒントを提供できるメトリック（バグの数や循環的複雑さなど）があります。すべての場合において、これらは単なるヒントであり、注意して使用する必要があります。

— アルセニ・ムルゼンコ
ソース

+1言ったことすべてに同意します。循環的複雑度またはLOCは、静的コード分析によって提供される単なるメトリックです。静的アナライザーは優れたツールですが、常識に欠けています。これらのメトリックは、人間の脳、好ましくは経験豊富なプログラマーが所有する脳で処理する必要があります。そうして初めて、特定のソフトウェアが不必要に複雑であるかどうかを知ることができます。