圈复杂度范围[关闭]

圈复杂度的类别是什么？例如：

1-5：易于维护
6-10：困难
11-15：非常困难
20+：接近不可能

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

我发现了：

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

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

在为解决方案运行代码指标时，结果在25以下的所有项目均显示为绿色。我不同意这一点，但我希望得到其他输入。

是否有普遍接受的范围复杂性的范围列表？

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

一些程序员是TDD的坚定拥护者，如果不先编写单元测试，就不会编写任何代码。其他程序员完全有能力创建完美的，无错误的程序，而无需编写单个单元测试。每个小组可以容忍的复杂程度几乎肯定会发生很大变化。

这是一个主观的指标；评估您的Code Metrics解决方案上的设置，并将其调整到您感到满意的最佳位置，从而获得合理的结果。

没有预定义的类别，由于以下几个原因，无法进行分类：

1. 一些重构技术只是从一个点移动的复杂性的另一个（而不是从你的代码的框架或一个屡试不爽的外部库，但是从一个地方到另一个代码库）。它有助于降低循环复杂性，并有助于说服您的老板（或喜欢不断增加图形的演示文稿的任何人）您花了很多时间来做一些很棒的事情，但代码仍然像以前一样糟糕。

2. 相反，有时，当您通过应用一些设计和编程模式来重构项目时，循环复杂性可能会变得更糟，而重构后的代码有望变得清晰：开发人员知道编程模式（至少他们应该知道它们），因此它简化了它们的代码，但是圈复杂度并未考虑到这一点。

3. 其他一些非重构技术根本不会影响循环复杂性，同时会严重降低开发人员代码的复杂性。示例：添加相关注释或文档。通过使用语法糖来“现代化”代码。

4. 在某些简单情况下，圈复杂度无关紧要。我喜欢whatsisname在他的评论中给出的示例：一些大型switch语句可能非常清晰，以一种更加OOPy的方式重写它们将不会很有用（并且会使初学者对代码的理解变得复杂）。同时，这些陈述是灾难性的，从循环复杂性角度而言。

5. 正如罗伯特·哈维（Robert Harvey）上文所述，这取决于团队本身。

在实践中，我看到了源代码，它具有很好的循环复杂性，但是非常糟糕。同时，我看到了具有高度循环复杂性的代码，但是理解它并没有太多的痛苦。

只是没有而且不可能有任何工具可以完美地表明给定代码段的优劣或易于维护。由于您无法编写一个程序，该程序将说出给定的绘画是一件杰作，而应该丢弃另一幅画，因为它没有艺术价值。

有一些指标被设计破坏（例如LOC或每个文件的注释数），并且有一些指标可以给出一些原始提示（例如错误数或圈复杂度）。在所有情况下，这些都只是提示，应谨慎使用。