問題タブ [cyclomatic-complexity]

複数のプロジェクトに分割された大規模なソース リポジトリがあります。ソース コードの健全性に関するレポートを作成し、対処が必要な問題領域を特定したいと考えています。

具体的には、サイクロマティックな複雑度の高いルーチンを呼び出し、繰り返しを特定し、糸くずのような静的分析を実行して、疑わしい (したがってエラーの可能性が高い) 構造を見つけたいと考えています。

このようなレポートを作成するにはどうすればよいでしょうか。

Javascript で循環的複雑度を計算するためのツールはありますか?

過去にサーバー側のコードに取り組んでいるときに、これが非常に役立つメトリックであることがわかったので、私が作成するクライアント側の Javascript に使用できるようにしたいと考えています。

「あなた/循環的複雑度の適切な制限は何ですか? 」を読んだ後、同僚の多くが、私たちのプロジェクトに関するこの新しいQAポリシーに非常に腹を立てていることに気付きました。

意味: 'if'、'else'、'try'、'catch' およびその他のコード ワークフロー分岐ステートメントは 10 個までです。右。「プライベート メソッドをテストしますか?」で説明したように、'、そのようなポリシーには多くの良い副作用があります。

しかし: 私たち (200 人 - 7 年間) のプロジェクトの開始時、私たちは喜んでログを記録していました (いいえ、ログに対するある種の「アスペクト指向プログラミング」アプローチにそれを簡単に委譲することはできません)。

そして、私たちのシステムの最初のバージョンが稼働したとき、ログ (ある時点でオフになっていました) が原因ではなく、常に計算されてから渡されるログ パラメーター(文字列) が原因で、巨大なメモリの問題が発生しました。 'info()' または 'fine()' 関数を呼び出して、ロギングのレベルが 'OFF' であり、ロギングが行われていないことを発見するだけです!

そのため、QA は戻ってきて、プログラマーに条件付きログを行うように促しました。いつも。

しかし現在、関数ごとに「移動できない」10 の循環的複雑度レベルが制限されているため、関数に入れるさまざまなログは負担として感じられると主張しています。 +1 循環的複雑度としてカウントされます!

そのため、関数に 8 つの「if」、「else」などがある場合、1 つの密結合された簡単に共有できないアルゴリズムと 3 つの重要なログ アクションがあります...条件付きログが実際にはそうでなくても、それらは制限に違反します。その機能の前述の複雑さの一部...

この状況にどのように対処しますか?
私のプロジェクトでは、(その「競合」による) 興味深いコーディングの進化がいくつか見られましたが、最初にあなたの考えを聞きたいだけです.

すべての回答に感謝します。 問題は「フォーマット」関連ではなく、「引数評価」
関連であると主張しなければなりません（何もしないメソッドを呼び出す直前に、非常にコストがかかる可能性のある評価）実際には aFunction() を意味し、 aFunction
() は文字列を返し、ロガーによって表示されるすべての種類のログ データを収集および計算する複雑なメソッドへの呼び出しである... またはそうでない (したがって、問題、および条件付きログを使用するため、「循環的複雑さ」の人為的な増加という実際の問題...)

私は今、あなたの何人かによって進められた '可変個引数関数' ポイントを取得します (ジョンに感謝します)。
注: java6 での簡単なテストでは、varargs 関数が呼び出される前に引数を評価することが示されているため、関数呼び出しには適用できませんが、「ログ取得オブジェクト」(または「関数ラッパー」) には適用できません。 ) は、必要な場合にのみ呼び出されます。とった。

私は今、このトピックに関する私の経験を投稿しました。
投票のために来週の火曜日までそこに残します。その後、あなたの回答の1つを選択します.
繰り返しますが、すべての提案に感謝します:)

最近、私たちの会社は、コード内の関数の循環的複雑度 (CC) を毎週測定し、どの関数が改善または悪化したかを報告し始めました。そのため、関数の CC にもっと注意を払うようになりました。

CC は、1 + 関数内の決定点の数 (if ステートメント、for ループ、select など)、または関数を通るパスの数として非公式に計算できることを読みました...

CC を減らす最も簡単な方法は、Extract Method リファクタリングを繰り返し使用することだと理解しています...

不明な点があります。たとえば、次のコード フラグメントの CC は何ですか?

1)

と

どちらも同じことを行いますが、for ステートメントのために最初のバージョンの方が CC が高くなりますか?

2)

と

言語が C# などの短絡評価を行うと仮定すると、これら 2 つのコード フラグメントは同じ効果を持ちますが、3 つの決定点/if ステートメントがあるため、最初のフラグメントの CC は高くなりますか?

3)

と

これら 2 つのコード フラグメントは異なることを行いますが、CC は同じですか? または、最初のフラグメントのネストされた if ステートメントの CC が高いですか? つまり、ネストされた if ステートメントは理解するのが精神的により複雑ですが、それは CC に反映されていますか?

現在、null の結果を返す可能性があるデータベースから大量のデータを受け取る Web アプリケーションに取り組んでいます。アプリケーションの循環的複雑度を通過するとき、多くの関数の重みは 10 ～ 30 の間です。ほとんどの場合、数値が大きい関数の大部分には、次のような行がたくさんあります。

これが私の質問につながります。これらの数値を下げるための最善の方法は何ですか? 現在、関数の大部分を 10 未満にすることを考えています。

小さくても複雑なコードを書くのに役立つアルゴリズムについて勉強しています。150 行の if-else ステートメントを書く代わりに、20 行でそれを行うアルゴリズムを設計できます。問題は、これらのアルゴリズムの多くが複雑になる可能性があり、それらを理解するために多くの計算が必要になることです。彼らのことを理解しているのも、この辺では私だけです。

コードの保守性のために、他の人が行うようにコードを書く方が良いでしょうか、それともアルゴリズムを使用する方が良いでしょうか?

LINQ と Lambda 式は循環的複雑さを軽減しますか? VS アナライザーが cc を増加させると、CodeRush は実際に cc の減少を示しているので、ちょっと興味があります。

.NETまたはJavaプロジェクトなどの単体テストケースを生成するための優れたツールはありますか？それは、ほぼ100％のコードカバレッジをカバーする単体テストケースを生成します。テストケースの数は、コードの循環的複雑度に正比例する可能性があり（ループと条件のネストが高いほど循環的複雑度が高くなります）、循環的複雑度が高いほど、テストケースのセットが生成されます。完全に機能することは期待していませんが（単体テストを作成し、生成後に実行する場合など）、変更するテストケースでテンプレートスタイルを使用できると思います。あなたの意図したニーズに合ったケース。ただし、適切なセットアップとティアダウンの方法も必要であり、依存関係がある場合に単体テスト用のモックオブジェクトを使用する必要があるかどうかを検出するのに十分です。それで、そのようなツールは存在しますか？