問題タブ [cyclomatic-complexity]

このコードの循環的複雑度を見つけて、いくつかのホワイト ボックス テスト ケースとブラック ボックス テスト ケースを提案する必要があります。しかし、コードの CFG を作成するのに問題があります。

テストケースについても助けていただければ幸いです。

この質問はスタイルに関するものだと思います。CC が非常に高い (そして行数が多い!) アルゴリズムを使用しています。それを減らしたいのですが、グループ化できるコードがあるので簡単です。問題は、このようにすると、一度しか呼び出されない「小さな」関数を呼び出す「大きな」関数ができてしまうことです。

私の意見では、大きな関数を小さな断片に分割することは、関数が 1 回呼び出されるにもかかわらず、コードの読みやすさ (この場合) に優れています。

どう思いますか？似たような場合はどうしますか？

職場では、いくつかのツールを使用して、いくつかのメトリック（主に循環的複雑度とLCOM）をキャプチャしています。これらを使用して、警告フラグを取得し、先制的なリファクタリングの取り組みをガイドします。これは、コードの品質を向上させる上で非常に有益です。

ただし、プロセスはビルドプロセスに関連付けられていません。別途実施します。さらに、（外部プロセスを実行するのではなく）ソースコードに固有のものを作成できるものを探しています。

コンパイラから実行できる注釈のグループと構成可能な注釈プロセッサを知っている人はいますか？コードが循環的/ LCOMのしきい値メトリックに準拠していない場合、ビルドが失敗しますか？

maven / antからckjm、checkstyle、pmdを実行できると思いますが、ソースコードで動作するものもあれば、バイトコードで動作するものもあります。コンパイルが始まる前にソースコードで動作する1つの統合ツールがあると便利です。

もう1つは、これを促進する可能性のある注釈のセットがあると便利です（コーナーケースで必然的に必要になるカスタマイズを可能にするため）。

次に、ツールを実行すると、デフォルトで厳密な（および構成可能な）メトリックしきい値が適用されます。ただし、（文書化され、正当な）より緩和されたしきい値で注釈が付けられたアーティファクトは除きます。減らすことができない/減らすべきではないいくつかの方法では、緩和された循環的複雑度が理にかなっています。動作のないプレーンPOJOの場合、LCOMをリラックスさせる必要があります...などなど。

見たりグーグルしたりしても、何も見つかりませんでした（できればオープンソース）。しかし、誰かがその種の何かを知っている場合に備えて、私はここで尋ねたほうがよいでしょう。

ありがとう。

ほとんどのプログラミング言語のメソッドの複雑さは、静的ソースコードアナライザーを使用して循環的複雑度で測定できます。SQLクエリの複雑さを測定するための同様のメトリックはありますか？

クエリが返されるまでの時間を測定するのは簡単ですが、クエリがどれほど複雑かを定量化できるようにしたい場合はどうすればよいでしょうか。

[編集/注]実行プランを取得することは有用ですが、この場合、必ずしもそれを特定しようとしているわけではありません。サーバーがクエリを実行するのがどれほど難しいかを探しているのではなく、開発者がクエリを書くのがどれほど難しいか、そして欠陥が含まれている可能性がどれほどあるかを特定するメトリックを探しています。

【編集・注2】確かに、複雑さの測定が役に立たない場合もありますが、役に立たない場合もあります。このトピックの詳細については、この質問を参照してください。

Automapperを使用して、モデルオブジェクトをデータベースオブジェクトにマップしたいと思います。データベースオブジェクトが30を超えるフィールドであり、モデルの20のプロパティのうち10をマップしたいとします。より複雑にするために、データベースに新しいレコードを挿入するときとは別に、レコードを更新するときに異なるプロパティをマップする必要があります。

私が使用している解決策は、2つの汎用クラスInsertとUpdate、および両方のマッピングを指定するマッピングプロファイルを作成することです。

以下の例：

ただし、マッピングしないすべてのプロパティに対してIgnore（）を定義する必要があるため、循環的複雑度が空（50以上）に入ると、マッピングが厄介になります。

新しいオブジェクトを作成することで、新しいレコードを挿入する際の問題を解決しました。

ただし、プロパティを新しいインスタンスではなく既存のオブジェクトにマップする更新では機能しません。

マッピングを完全に制御するために、DynamicMap（）を避けたいと思います（したがって、ランダムなプロパティを誤ってマッピングすることはありません）。私の目標は、循環的複雑度の問題を解決することです。ValueInjecterやその他のメソッドを提案しないでください。AutoMapper内の解決策を探しています。

ラムダを使用してリストを初期化すると、ILの循環的複雑度が高くなります。なぜ、どのようにしてこの複雑度を取り除くのでしょうか。たとえば、次のコードを使用すると、クラスの静的コンストラクター（実際にはコンパイラーによって生成されます）が非常に複雑になります。1+リスト数。

注：複雑さは次のように計算されますNDepend

if/while/for ステートメントを含む決定ステートメントの数が多いメソッドでは、循環的複雑度が高くなります。では、どうすれば改善できるでしょうか。

CCが10を超えるメソッドのCCを減らすことになっている大きなプロジェクトを処理しています。この問題を伴うメソッドはたくさんあります。以下に、私が遭遇した問題を含むコード パターン (実際のコードではない) の例をいくつか挙げます。それらを単純化できる可能性はありますか？

多くの意思決定ステートメントが発生するケースの例:

ケース 1)

ケース 2)

ケース 3)

Delphi（2010）で循環的複雑度のAPIを探しています。ソースコードを分析し、すべてのクラスのすべてのメソッドの循環的複雑度を報告するプログラムを作成する必要があります（SourceMonitorと同じように）。
他のソフトウェアを使用することはできません。本当に作成する必要があります。
それを行うdelphi2010のAPIを知っている人はいますか？

Clojure関数の循環的複雑度を計算するための合理的な方法は何でしょうか？「if」や「cond」などの関数に基づいて決定ポイントを数えるのは簡単ですが、マクロでは扱いにくくなります。誰かがClojureまたはおそらく別の関数型言語でこれを試しましたか？

いくつかの決定点を別のメソッドにリファクタリングすることで CC を減らすプライベート メソッドを使用すると、実際のメソッドの CC が減り、読みやすくなりますが、テストで完全なブランチ カバレッジを得るための労力は減りません。

これは正当化できますか？フィールド経験は？