Language agnostic 什么是圈复杂度？

我经常看到的一个术语是“圈复杂度”。在这里，我看到了一些关于“如何计算语言X的CC”或“如何用最小CC量计算Y”的问题，但我不确定我是否真正理解它是什么

在另一方面，我看到了一个解释，基本上说“一个方法中的决策数量。每个if、for、&&etc将+1添加到CC“分数”）。真的是这样吗？如果是，为什么这么糟糕？我可以看出，人们可能希望保持if语句的数量相当低，以保持代码易于理解，但这真的是它的全部吗

---

或者有更深层次的概念吗？

我不知道有更深层次的概念。我相信它通常是在可维护性指数的上下文中考虑的。特定方法中的分支越多，维护该方法操作的心智模型就越困难（通常）

更高圈复杂度的方法也更难在单元测试中获得完整的代码覆盖率。（谢谢！）

---

当然，这带来了可维护性的所有其他方面。错误/回归的可能性等等。不过，核心概念非常简单。

是的，确实如此。代码可以执行的路径越多，必须测试的内容越多，出错的概率越高。

就是这样，想法是在一个CC值较低的方法中，分叉、循环等较少，这都会使方法更复杂。想象一下，使用分析器查看500000行代码，并看到两个CC值较高的方法。这样，您就可以专注于重构这些方法，以便更好地理解（高CC的错误率也很高也很常见）

圈复杂度度量为执行通过该块的每条路径，必须使用不同参数执行代码块的次数。较高的计数是不好的，因为它会增加逃离测试策略的逻辑错误的机会。

例程中的每个决策点（循环、开关、if等）本质上可以归结为一个等价的if语句。对于每个

if

，您有两个可以采用的代码路径。因此，第一个分支有两个代码路径，第二个分支有4个可能的路径，第三个分支有8个，依此类推。至少有2**N个代码路径，其中N是分支数

这使得我们很难理解代码的行为，也很难在N超过某个小数值时对其进行测试。

考虑函数的长度，从出口到入口有一条额外的边。圈复杂度是我们在不将图分成两部分的情况下可以进行的最大切割数

例如：

function F:
    if condition1:
       ...
    else:
       ...
    if condition2:
       ...
    else:
       ...

---

您可能可以直观地看到为什么链接图的圈复杂度为3。

圈矩阵复杂度基本上是一种度量，用于找出需要更多关注可维护性的代码区域。它基本上是重构的输入。

---

在避免深层嵌套循环、条件等方面，它明确指出了代码改进的领域。

Wikipedia可能是您在这方面的朋友：

基本上，你必须把你的程序想象成一个

复杂性（…）定义为：

M = E − N + 2P

在哪里

• M=圈复杂度
• E=图形的边数
• N=图形的节点数
• P=连接部件的数量

---

CC是一个试图捕捉程序有多复杂以及在单个整数中测试它有多困难的概念。

圈复杂度实际上只是一个可怕的时髦词。事实上，它是软件开发中用于指出代码更复杂部分的代码复杂度度量（更可能是小车，因此必须非常仔细和彻底地测试）。您可以使用E-N+2P公式进行计算，但我建议您使用插件自动计算。我听说过一条经验法则，您应该努力将CC保持在5以下，以保持代码的良好可读性和可维护性

---

我最近刚刚在Java项目上试用了，它有一个非常好、简洁的帮助文件，当然会与您的常规Eclipse帮助集成，您可以阅读更多关于各种复杂性度量的定义以及改进代码的技巧和窍门。

我听到的另一个有趣的观点是：

---

代码中缩进最大的位置应该具有最高的CC。这些通常是确保测试覆盖率的最重要的区域，因为预计它们将更难阅读/维护。正如其他答案所指出的，这些也是确保覆盖率的更困难的代码区域。

就是这样。但是，每个br“case”或“switch”语句的anch倾向于计算为1。实际上，这意味着CC讨厌case语句以及任何需要它们的代码（命令处理器、状态机等）.

到目前为止提供的答案没有提到软件质量与圈复杂度之间的相关性。研究表明，拥有较低的圈复杂度度量应该有助于开发质量更高的软件。它可以帮助提高可读性、可维护性和可移植性等软件质量属性。一般来说应尝试获得介于5-10之间的圈复杂度度量

使用圈复杂度这样的度量标准的原因之一是，一般来说，人类只能跟踪大约7（正负2）在你的大脑中同时存在一段信息。因此，如果你的软件过于复杂，有多条决策路径，你就不可能想象出你的软件将如何运行（即，它将具有很高的圈复杂度指标）。这很可能会导致开发出错误或充满bug的软件。Mor

Cyclocmatic complexity = Number of decision points + 1