圈复杂度范围

Question

什么是圈复杂度的范畴？例如：

1-5:易于维护

6-10:困难

11-15:非常困难

20+：接近不可能

多年来，我一直认为10是极限。除此之外的任何事情都是不好的。我正在分析一个解决方案，并试图确定代码的质量。当然，圈复杂度并不是唯一的衡量标准，但它可以有所帮助。有些方法的圈复杂度为200+。我知道这很糟糕，但我很想知道更低的范围，就像我上面的例子。

我发现这：

卡内基梅隆大学的上述参考值为圈复杂度值定义了四个粗略范围：

• 1到10之间的方法被认为简单易懂。
• 在10到20之间的值表示更复杂的代码，这可能仍然是可理解的；但是，由于代码可以使用更多的可能分支，测试变得更加困难。
• 20及以上的值是典型的具有大量潜在执行路径的代码，只有通过极大的困难和努力才能完全掌握和测试。
• 更高的方法，例如> 50，肯定是不可维护的。

当为解决方案运行代码度量时，结果显示任何低于25的指标都是绿色的。我不同意这一点，但我希望得到其他的意见。

是否有一个公认的圈复杂度范围列表？

Answer 1

我认为这取决于您的编程人员的能力，而且在很大程度上取决于您作为经理的敏感性。

有些程序员是TDD的坚定拥护者，如果不首先编写单元测试，就不会编写任何代码。其他程序员完全能够在不编写一个单元测试的情况下创建完美的、无bug的程序。每个群体所能容忍的圈复杂度水平几乎肯定会有很大的差异。

这是一个主观的度量；评估您的Code解决方案的设置，并将其调整到一个让您感到舒服的甜蜜点，从而给您带来合理的结果。

Answer 2

没有预先定义的类别，也不可能进行分类，原因有几点：

1. 有些重构技术只是将复杂性从一个点转移到另一个点(不是从代码到框架或经过良好测试的外部库，而是从一个位置到另一个代码库)。它有助于降低圈复杂度，并帮助您说服老板(或任何喜欢使用不断增加的图形的演示文稿的人)，您花了大量的时间来做一些伟大的事情，但是代码仍然和以前一样糟糕。
2. 相反，有时，当您通过应用一些设计和编程模式来重构一个项目时，圈复杂度可能会变得更糟，而重构的代码则会变得更清楚:开发人员知道编程模式(至少他们应该了解它们)，所以它简化了他们的代码，但是圈复杂度没有考虑到这一点。
3. 其他一些非重构技术根本不影响圈复杂度，同时严重降低了开发人员代码的复杂性。例如:添加相关评论或文档。“现代化”的代码使用语法糖。
4. 在一些简单的情况下，圈复杂度是不相关的。我喜欢示例在他的评论中用什么名字：一些大型的switch语句可能非常清晰，以一种更OOPy的方式重写它们将不是很有用(并且会使初学者对代码的理解复杂化)。同时，这些说法也是一场灾难，从圈的复杂性来看。
5. 正如罗伯特·哈维上面所说的，这取决于团队本身。

在实践中，我看到了源代码具有良好的圈复杂度，但这是可怕的。同时，我看到代码具有很高的圈复杂度，但是我没有太多的痛苦去理解它。

它只是没有，也不可能有任何工具，可以完美地指出，一个给定的代码是好的还是坏的，或者它是多么容易维护。因为你不能编程一个应用程序，它会告诉你某一幅画是一幅杰作，而另一幅画应该被扔掉，因为它没有艺术价值。

有些度量被设计打破(比如LOC或每个文件的注释数量)，还有一些度量可以给出一些原始提示(比如bug的数量或圈复杂度)。在所有情况下，这些只是提示，应该谨慎使用。