8

次のコードでは、sonarqube はメソッドの循環的複雑度を 9 として計算します。

String foo() {
    if (cond1) return a;
    if (cond2) return b;
    if (cond3) return c;
    if (cond4) return d;
    return e;
}

http://docs.sonarqube.org/display/SONAR/Metrics+-+Complexityの計算規則に従って、9 の複雑さが正しいことを理解しています。したがって、メソッドの複雑さは = 4 (if) + 4 (return) + 1 (method) = 9 です。

単一の出口点があれば、この複雑さを軽減できます。

String foo() {
    String temp;
    if (cond1) { 
        temp = a;
    } else if (cond2) {
        temp = b;
    } else if (cond3) { 
        temp = c;
    } else if (cond4) {
        temp = d;
    } else {
        temp = e;
    }
    return temp;
}

このコードは以前のバージョンよりも雑然としていて読みにくいと思います。また、メソッドにリターン オン ガード条件を使用することは、より良いプログラミング手法であると感じています。それでは、循環的複雑度の計算に return ステートメントが考慮される正当な理由はありますか? 単一の出口点を促進しないように、計算のロジックを変更できますか。

4

4 に答える 4

2

これは循環的複雑度に関する既知の問題です。

また、循環的複雑度が役に立たないと考える十分な理由もあります。これは SLOC と強く相関し、実際のバグとは弱くしか相関しません。実際、SLOC は、循環的複雑度と同じくらい優れた欠陥の予測因子です。他のほとんどの複雑さの指標についても同じことが言えます。

スライド 16 あたりから始まるhttp://www.leshatton.org/Documents/TAIC2008-29-08-2008.pdfを参照してください。

于 2014-05-22T09:53:30.710 に答える
2

他の回答は、関連する計算について良い点を示しています。

コードが読みにくいというあなたの主張は誤りであることを指摘したいと思います。

String foo() {
  String output = e;
  if (cond1) output = a;
  else if (cond2) output = b;
  else if (cond3) output = c;
  else if (cond4) output = d;

  return output;
}

これは、 return ステートメントで示した例と同じくらい読みやすいです。中括弧のない if ステートメントを許可するかどうかはスタイルの問題であり、おそらくすべてのコードで一貫している必要があります。

循環的複雑度が対処するより重要な問題は、cond1、cond2 などの値の計算に副作用がある場合、つまり、この場合、それらがフィールドではなくステートフル メソッドである場合、コードの概念的な複雑さがはるかに高くなるということです。できない場合よりも早く戻る可能性があります。

于 2014-05-26T07:30:56.157 に答える