8

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

4

3 回答 3

18

我怀疑这种差异可能是由于延迟执行造成的。当您将 LINQ 与 lambda 表达式一起使用时，您指定的是在您随后迭代集合时将运行的代码。

就我个人而言，我并不担心圈复杂度，但我绝对确定（如果使用得当）LINQ 会提高可读性。这才是我真正关心的:)

于 2009-03-19T14:15:38.317 回答
2

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

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

但是我很快就用 Get() 方法替换了一些 LinQ 查询，这些方法为我提供了相同的数据和额外的好处。

我在我的构建/发布脚本中保持我的 Fxcop 开启，所以我从来没有在没有达到 25 的圈复杂度目标的情况下部署任何东西。

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

当我的伙伴提出一个非常糟糕的代码时，这让我在讨论中获得了一些观点： 这行得通，这才是最重要的。

我的建议是：保持你的圈复杂度低于 25。 这可以帮助你保持每个方法都足够简单，以便进行良好的维护。

于 2011-02-09T23:32:23.817 回答
1

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

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

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

但是，代码的可读性要高得多。

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

于 2014-07-11T21:49:41.090 回答