web-dev-qa-db-ja.com

循環的複雑度密度は、ソフトウェア品質の優れた指標ですか？

ここで、循環的複雑度密度を次のように定義します。

Cyclomatic complexity density = Cyclomatic complexity / Lines of code

サイクロマティックな複雑さに関する以前の議論を読んでいましたが、有用性が混在しているというコンセンサスのようなものがあるようです。そのため、単純なコード行（LOC）メトリックでそれを使用する強い動機はおそらくありません。つまりクラスまたはメソッドのサイズがしきい値を超えて大きくなると、欠陥が発生したり、設計の選択が不十分だったりする可能性が高くなります。

循環的複雑度（CC）とLOCは相関する傾向があるため、より単純なLOCメトリックを使用することについての議論があります。ただし、コードの特定の領域内で複雑度が高い、つまり一部のコードの実行ブランチの密度が（平均と比べて）高いという異常値のケースがあり、それが相関する傾向があるかどうか疑問に思っています欠陥の存在。

そのような複雑さの密度測定基準の使用に関する賛成または反対の証拠、または経験はありますか？

あるいは、LOCとCCの両方のしきい値を設定することをお勧めします。どちらかのしきい値を渡すことは悪いと見なされます。

code-qualityqualitycyclomatic-complexity
3
redcalx

良いソフトウェア品質指標はありません-少なくともどれもまだ知られていません。長年の研究はまだ私たちに良いものを提供していません。

したがって、提案された指標のいずれかがソフトウェア品質の優れた指標であるかどうかの答えは、残念な「いいえ」です。

不良ソフトウェアの妥当な指標となるいくつかのメトリックがあります。しかし、悪いソフトウェアの兆候がないからといって、ソフトウェアは良いものにはなりません。さらに、これらのインジケーターは非常にうるさく、多くの例外があるため、不正なコードを自動的に拒否することは実際には現実的ではありません。

研究者はこれらの測定基準について議論し、測定基準とバグを関連付けますが、通常、これらの相関関係は「より大きなプログラムにはより多くのバグが含まれている」よりも強力ではありません。として ウィキペディアのこのエントリ は認めます：

この観察の本質は、より大きなプログラム（McCabeの測定基準で定義されているより複雑なプログラム）には、より多くの欠陥がある傾向があるということです。この関係はおそらく真実ですが、商業的には役に立ちません。

その結果、これらのメトリックは商業の世界ではほとんど使用されません-時間もお金も節約されません。

これは研究者がより良いものを探すことを止めるべきではありません。しかし、これまでのところ、私の意見では、ほとんど実用的な使用法のない理論的な演習です。

商用ICTでの20年間の作業中に、実際に使用されている2つのメトリックに遭遇しましたが、どちらも自動化できません。

  • 「満足している有料顧客の数」、または「どのくらい私たちを稼ぐのか」とも呼ばれます。
  • ピアがコードを読み取っているときの「1分あたりのWTF」。

これがこの画像が人気である理由です-私は複数の店で見ました： WTF per minute

6
Sjoerd

以下を検討してください。

define dispatch_message (message_id, message_contents)
    if (message_id == MESSAGE_ID_1)
        FirstMessageId(message_contents).dispatch()
    else if (message_id == MESSAGE_ID_2)
        SecondMessageId(message_contents).dispatch()
    ...
    else if (message_id == MESSAGE_ID_N)
        NthMessageId(message_contents).dispatch()
    else
        raise_or_throw_an_error
    end if
end function

この関数は2N + 5行のコードで構成され、カウント方法に応じてN + 1またはN + 3の循環的複雑度を持ちますraise_or_throw_an_error。 Nが200であるとします。複雑度の密度は約1/2です。どういう意味ですか？一方、行数が4005、複雑度が2000を超える関数は意味があります。

2000年以上の複雑さにもかかわらず、私の機能は完全にひどいものではありません。 （さて、それはひどいです。これを行うにはより現代的な方法があります。）これは驚くべきことに、非常に高い信頼性のシステムではかなり一般的な構成です。正しく行われれば、関数が何をしているのかはかなり明白です。

SLOCを複雑度で分割する場合の1つの問題は、SLOCと複雑度の間に強い相関があることです。私の機能は異常です。あなたの測定基準が示すすべては私の機能が異常であることです。もう1つの極端な例として、循環的複雑度が1の非常に長い自動生成関数を考えます。これらも、それ自体ではそれほど問題ではありません。 （これは、40000行の長い関数ではなく、調べる必要があるジェネレータです。）

SLOCと複雑さの比率の両極端は、バグを探す場所ではありません。それは真ん中のどこかにあります。残念ながら、ここにほとんどの関数があります。 SLOCと複雑さは誤報を与えますが、それらの誤報は調査する価値があります。 SLOCと複雑さの比率のメトリックに同じことが当てはまるとは思いません。最もバグの多い関数は、SLOCと複雑度の比率が類似している多数の非アラーム関数の中に隠されている可能性が高いです。

6
David Hammen