問題タブ [cyclomatic-complexity]

以下のような方法があります。循環的な複雑さを避けるためにご協力ください。

Max OS X で自分のコードの McCabe スタイル関数の複雑さをテストするには、どのツールを使用できますか?

Linux 用のpmccabeがあります。これは、私の部門のマシンにあり、彼らが私に使用することを望んでいます。特定のプロジェクト ファイル内の各関数を分析し、McCabe スタイルの整数としての関数の複雑さを含む、それぞれのデータを吐き出します (出力例)。同じ機能のものが欲しいです。

ソナーは、次のコードに対して重大な違反エラー (「Cyclomatic Complexity」) を返します。次のメソッドは、特別な形式で日付を取得するために使用されます (例: 14-02-3(Year-month-weekid))。

この違反を克服するにはどうすればよいですか?

この質問: CA1502 のカスタムしきい値で は、コード分析でコード メトリック ルールのカスタムしきい値を設定する方法について説明しています。

私は同じ問題を抱えていますが、古い質問は時代遅れだと思います。

繰り返す：

特に、メソッドのコードの複雑度が 20 を超える場合に Build が失敗するようにしたいと考えています。残念ながら、ルール CA1502 のしきい値は 25 です。

このルールは、循環的複雑度が 25 を超えると違反を報告します。

どうにかしてこれを変えることはできますか？

受け入れられている答えは、.fxcop ファイルを編集してルールを含めることです。Visual Studio 2013 Ultimate では、コード分析とコード メトリックが統合されました。しかし、.fxcop ルールはないようです。これは、fxcop が別の拡張機能であったときに使用されたと思います。

Visual Studio で生成された .ruleset ファイルのしきい値を編集する方法はありますか? または、最近のバージョンで .fxcop ファイルを取得する方法と場所を見逃していませんか?

McCabe 式を使用する場合

M = EN + 2C

データが一方向のみに流れるように制限されている場合は考慮されますか? それが実際に起こっているかどうかに関係なく、グラフはデータが多方向に流れていることを示しているようです。

一方向のデータフローを持つコードベースと、データが行き来できる別の (非常に類似した) コードベースのコードベースは、それほど複雑ではありません。

Facebook、MVC、および Flux に関するこの記事は、私が求めていることの良い例です: http://www.infoq.com/news/2014/05/facebook-mvc-flux。彼らは当初、MVC を使用してデータをやり取りしていました (ビューからモデルへ、またはその逆)。Flux の MVC を切り替えると、データは一方向に流れました。

サイクロマティックな複雑さと複数の return ステートメントについて読みましたが、複数の return ステートメントに対する意見が異なるため、少し混乱しています。

まず第一に、Cyclomatic Complexity の計算中に、複雑さを増すエンドポイントとして各 return ステートメントをカウントする必要がありますか? 式 (M = E - N + 2*P) に return ステートメントを追加すると、1 増加しますよね?

単純な健全性チェックに使用されるガード句は、ネストされた if 句の代わりに、できるだけ早く返すための別の方法です。ただし、これにより、コードに戻りステートメントが追加され、CC が増加しますか?

CC に関してガード句と複数の return ステートメントを使用するための一般的なベスト プラクティスはありますか?

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

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

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

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

メソッドが、かなり大きな列挙型の値に応じてアクションを選択するとします。私たちのソナーは、このメソッドの高いサイクロマティックな複雑さ (当然、case ステートメントの数について) について不平を言っています。

大規模な switch case ステートメントは OOP で実際に最適なスタイルではないことはわかっていますが、複雑なオブジェクト ツリーを構築する代わりにそれらを使用するのが適切な場合があります (私の場合は演算子トークンを評価するパーサー)。

私の懸念は今、それに対処する方法ですか？そのようなスイッチケースを意味のあるように分割する設計パターンはありますか? または、CC の測定からクラスを除外できますか (また、CC の測定から除外する必要があります) (高い CC を簡単に回避できる他の方法が含まれている可能性があるため)。

それは本当に重要なことではありません。プロジェクトに削除できないという警告が表示されるのが嫌いです ;o)

編集：コードサンプル