linq - LINQ と Lambda 式は循環的複雑さを軽減しますか?

Question

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

Answer 1

不一致は実行の延期が原因である可能性があると思います。ラムダ式で LINQ を使用する場合は、コレクションを反復処理する場合に実行されるコードを指定しています。

個人的には循環的複雑度についてはそれほど心配していませんが、(適切に使用すれば) LINQ が可読性を向上させることは間違いありません。それが私が本当に気にかけていることです:)

Answer 2

私はちょうど同じ質問に出くわしました。実際、ラムダは循環的な複雑さを増加させる可能性があります。私はテストを行い、 Where() 句はそれを賢明に増やすことができます。

読みやすさは、最優先事項の 1 つです。

しかし、LinQ クエリの一部を Get() メソッドに置き換えるのにそれほど時間はかかりませんでした。これにより、同じデータと追加の利点が得られました。

---

ビルド/パブリッシュ スクリプトで Fxcop をオンにしておくので、循環的複雑度の目標である 25 に到達するまで何かをデプロイすることはありません。

大変ですが、頑張る価値はあると思います。

これは、私の仲間が非常に悪いコードを持ってきたときに、議論のポイントを与えてくれます。 これは機能します。これが重要です。

---

私のヒントは、サイクロマティック複雑度を 25 未満 に保つことです。これにより、すべてのメソッドを適切なメンテナンスのために十分にシンプルに保つことができます。

Answer 3

Jon Skeet は、この質問にかなり簡潔に答えました。C# のような高級言語での私の経験では、LINQ のようなシンタックス シュガー パッケージが開発に追加する価値のために、循環的複雑度を測定する価値が低下することを付け加えたいと思います。

過去 10 年間、言語が進化するにつれて、ネット上の多くの人が、循環的複雑度とコード行との間に強い相関関係があることを示しており、そのような手段が実際にどれだけの価値をもたらすかについて疑問を投げかけています。別の見方をすれば、コード品質の尺度としての CC の切り下げは、実際には読みやすさの重要性の主張であるということです。

たとえば、条件を foreach ループ内に配置すると、条件がコードとして評価され、適切な数のコード パスがカウントされます。一方、関数ツリーをコレクションに適用すると、反復処理が行われます (例: Where(evalStr => evalStr == origStr) 条件をループの外側に移動し、コンパイラによって生成されたコードに入ります。分岐の数は同じですが、条件分岐はループの一部ではありませんが、CC は foreach ループのそれを超えて増加し、実際の分岐数に加えて匿名メソッド (ラムダとデリゲート) を使用すると「ペナルティ」が発生します。 Where 関数を使用すると、必要な場合にのみループが繰り返されるように、反復されたコレクションを事前に調整できます。

ただし、コードははるかに読みやすくなっています。

最後に、LINQ IQueryable 関数内で使用されるブール式を単体テストする必要がないと判断した場合、表向きは、例外がある場合、それは高次 (ビジネス レベル) の例外であるためです (間違った値がテストされ、間違った演算子、間違ったオペランドなど) 言語の理想的ではない使用法 (if の代わりにスイッチを使用する、三項の代わりに if を使用するなど) とは対照的に、循環的複雑度の測定では、次のことを考慮する必要があります。 ) 関数は私の CC を増やすべきではありません。循環的複雑度の測定は、より良いコードの作成には役立ちません。どちらかといえば、単純化が不要または望まれない開発者の単純化傾向を人為的に増加させることになります。