11

循環的複雑度とは何ですか？

ただし、「本質的な循環的複雑度」と呼ばれる別の用語があります。

コードのこれら2つのメトリックの違いと類似点は何ですか？それらの典型的な許容値は何ですか？また、コードを理解するには、EssentialCyclomaticComplexityがより適切なメトリックであることも学びました。一方、実装の観点からは、循環的複雑度が最も関連性があります。もしそうなら、なぜですか？

4

1 に答える 1

15

ご存知のように、サイクロメトリック複雑度は、メソッドまたは関数を介して可能な独立したパスの数を効果的に測定します。これは、メソッドのテストがどれほど複雑かを示しています。

ただし、本質的な循環的複雑度は、適切に構造化された複雑度を削除した後、どれだけの複雑度が残っているかを示します。適切に構造化された複雑さの例は、ループの条件がループの開始時に記述されているforループです。ただし、たとえばパスの途中でbreakステートメントを使用してループから抜け出すと、構造化コンポーネントが壊れます。同様の状況は、単一の関数に多数のreturnステートメントがある場合です。

それで、これは私たちに何を伝えますか？

CCが高い関数、つまりテストが難しい関数があると想像してみてください。この関数の必須CCが低い場合は、この関数を他の小さな関数に分割するのがかなり簡単で、個別にテストするのが簡単であることを意味します。本質的な複雑さが高い場合、複雑さを理解するのがより困難になるため、このリファクタリングはより困難になります。

したがって、本質的に複雑なコードは、コードの保守と理解が難しいことを意味します。私たちが言えるこのコードは低品質です。複雑度の高いコードはテストが困難ですが、一般に、本質的な複雑度が低い場合は、これについてより簡単に何かを行うことができます。

どの値を使用するかは常に議論の余地があり、アプリケーションのタイプと使用する言語によって多少異なります。たとえば、関数内で例外をスローすると、その関数は構造化されなくなります。適切に使用された場合の例外は、明らかに良い習慣と見なされます。同様に、関数の先頭にあるパラメーターを検証してすぐに返すことは、（私の意見では）より明確なコードをもたらすことができる一般的な方法です。繰り返しますが、これは構造化されていない構造です。したがって、基本的なレベルの本質的な複雑さを受け入れることができると想像できます。

.NETまたはJavaでのエンタープライズスタイルのアプリケーションに対する私の個人的な制限は次のとおりです。

CC<=16およびECC<=6

より多くの「複雑な」アプリケーションについては、C / C ++で言うと、より厳しい制限を提案します。

CC<=10およびECC<=4

于 2012-12-04T22:11:34.487 に答える