LINQ和Lambda表达式是否会降低Cyclomatic复杂度？

Question

LINQ和Lambda表达式是否会降低圈复杂度？只是好奇，因为当VS分析器增加时，CodeRush实际上显示了cc的减少。

Answer 1

我怀疑这种差异可能是由于延期执行造成的。当您使用带有lambda表达式的LINQ时，您将指定将运行的代码，如果然后迭代该集合。

就个人而言，我并不那么担心圈复杂性，但我绝对相信（如果使用得当）LINQ可以提高可读性。这就是我真正关心的事情：）

Answer 2

我刚刚提出同样的问题，事实上，lambda可以增加圈复杂度。 我做了测试，Where（）子句可以明智地增加它。

可读性确实是您的首要任务之一。

但是我没有花太多时间用Get（）方法替换一些LinQ查询，这些方法为我提供了相同的数据和额外的好处。

---

我将我的Fxcop保留在我的构建/发布脚本中，所以我从未在没有达到25的目标的情况下部署一些东西来解决圈复杂问题。

这很难，但我认为这是值得的。

当我的伙伴提出一个非常糟糕的代码时，这给了我一些讨论点： 这是有效的，这才是最重要的。

---

我的提示是：将您的圈复杂度保持在25以下。 这可以帮助您保持每种方法都足够简单，以便进行良好的维护。

Answer 3

Jon Skeet几乎简洁地回答了这个问题。我想补充一点，根据我对C＃等高级语言的经验，测量圈复杂度的价值降低了，因为LINQ等语法糖包的价值增加了​​开发。

在过去十年中，随着语言的发展，网络上的许多人已经说明了圈复杂度和代码行之间的强相关性，使得他们中的许多人质疑这种度量实际带来了多少价值。另一种看待它的方法是将CC作为代码质量度量的贬值实际上是对可读性重要性的断言，因为一个通常与另一个相反。

例如，如果我在foreach循环中放入一个条件，则将条件计算为我的代码，并计算适当数量的代码路径。另一方面，如果我将函数树应用于我正在迭代的集合（例如Where（evalStr =＆gt; evalStr == origStr）我将条件移动到循环外部并转换为编译器生成的代码。仍然是相同数量的分支，但条件不是循环的一部分，但CC增加超过foreach循环，使用匿名方法（lambdas和委托）的＃34;惩罚＆＃34;实际的分支计数.Where函数让我对迭代集合进行预处理，以便循环只在需要时迭代。

然而，代码更具可读性。

最后，如果决定在LINQ IQueryable函数中使用的布尔表达式不需要进行单元测试，那么表面上是因为如果存在异常，则它是一个更高阶（也称为业务级）的异常（错误的值）正在测试，错误的操作符，错误的操作数等），而不是语言的使用不太理想（使用开关而不是if，如果不是三元等），那么测量圈复杂度应该考虑到这一点： Where（）函数不应该增加我的CC。测量圈复杂度不会有助于制作更好的代码;如果有的话，它会人为地增加开发人员在不需要或不需要简化的情况下简化的倾向。