Language agnostic 圈复杂度和本质圈复杂度有什么区别？

已经有一个问题了

然而，还有另一个术语叫做-本质圈复杂度

代码的这两个度量之间有什么区别和相似之处？他们的典型公认价值观是什么？ 此外，我还了解到，为了理解代码，基本圈复杂度是一个更相关的度量。而从实现的角度来看，圈复杂度是最相关的。

---

如果是这样，原因是什么？

循环复杂度可以有效地度量通过方法或函数的可能独立路径的数量。这告诉我们测试方法有多复杂

然而，基本循环复杂度告诉我们，一旦我们去除了结构良好的复杂度，剩下多少复杂度。结构良好的复杂性的一个例子是for循环，其中循环的条件在循环的开始处声明。但是，如果我们用一个中断语句来打破循环，例如在路径中间的某个地方，我们就破坏了结构化的组件。类似的情况是，我们在一个函数中有许多返回语句

那么这告诉我们什么呢

假设我们有一个高CC的函数：一个很难测试的函数。现在，如果这个函数有一个低的基本CC，这意味着它很容易将这个函数分解成其他更小的函数，这些函数更容易单独测试。当本质复杂性很高时，重构就比较困难，因为复杂性更难理解

因此，具有高度基本复杂性的代码意味着代码更难维护和理解。我们可以说这段代码质量较低。复杂度高的代码更难测试，但一般来说，当基本复杂度较低时，我们可以更容易地进行测试

要使用的值始终由参数决定，在某种程度上取决于应用程序的类型和使用的语言。例如，在函数内部引发异常会导致该函数未结构化。显然，正确使用例外情况被视为良好做法。类似地，在函数顶部验证一个参数并立即返回也是一种常见的做法（在我看来）可以产生更清晰的代码。同样，这是一个非结构化的构造。所以我们可以想象，我们可以接受一个基本层次的本质复杂性

我个人对.NET或Java中企业风格应用程序的限制是：

---

快速浏览维基百科（大概你已经看过了吧？）ECC似乎是CC，因为它实际上忽略了流控制的“良好结构”位、

如果else

、

for

、

while

，等等。这将加重更难推理的控制结构的权重<代码>中断，

转到

，

抛出

，等等。例如，它不会减少实现完全测试覆盖所需的工作；CC在这方面仍然相关。这就是你的意思，还是我遗漏了什么？@Rook是的，我已经通过wiki。我不关心这里的测试覆盖率。比方说，我得到了一个代码，我被要求通过逆向工程来建模（例如UML图）。同样的，什么对我来说更相关？ECC还是CC？我在某个地方读到，ECC对于理解代码和CC对于实现更为相关。就我个人而言，我认为“两者都不是”。在处理软件开发时，我认为从项目管理的角度来看，两者都是有趣的。除此之外（例如，在对现有系统建模时），它们似乎只是好奇而已。我相信Visual Studio中的代码度量结果并没有提供与基本圈复杂度相关的细节。就我在你的帖子中所能理解的，基本圈复杂度不能从圈复杂度中推断出来。获得基本圈复杂度数字的方法是什么？@RBT-没错。我所知道的唯一计算基本CC的工具是McCabe IQ（）。但我已经很多年没看过了