整个代码库的 C 代码复杂度指标 [关闭]

Question

我使用 Mccabe 代码复杂度作为衡量我的代码库的指标，但它只给出了每个单独函数的代码复杂度分数。 总体代码复杂度分数由我的代码库中所有函数的分数之和给出。 我试图提出一个规范化的指标（考虑代码行）来反映我们努力降低代码库复杂性的趋势。 （我们知道删除/添加函数会改变复杂度分数，但复杂度不会改变）。 有标准的方法吗？我的意思是平均复杂度之类的东西？

Answer 1

McCabe 代码复杂度指标意味着针对函数，而不是整个程序。简单来说：如果一个函数的 McCabe 数超过了一定的限制（俗称意大利面条代码），你应该把它分解成几个更简单的函数。

实际衡量的是可能路径的数量。这对于单个函数来说相对容易，但对于多个函数来说，如果它们是依赖的，即如果这些函数相互调用，那就相当复杂了。

因此，如果您有独立的功能（例如：库），您可以添加它们，但如果它们是依赖的（例如：完整的程序），您必须计算整个程序中所有可能的路径。如果一个节点是一个函数，你必须包含 McCabe 数，如果不是（例如：一个简单的分支），你可以将它包含为 1（一），就像在单个函数中一样。

所以：

• 独立函数：全部添加
• 独立功能：
  • 以线性方式调用（单个路径）：将它们全部添加
  • 以两种方式调用（两条线性路径）：在每个路径中添加函数并添加两条路径，就像函数中的分支一样
  • 以 n 种方式调用（n 个线性路径）：在每个路径中添加函数并添加所有路径，就像函数中的分支一样
  • 依赖函数：与上面类似，但由于您需要计算所有可能的路径，因此您很快就会得到大量数据。

当然，您可以将这一切自动化。好的，你需要为你的语言编写一个解析器，它能够计算所有可能的路径，如果这值得花钱……我不知道。

此外：您可以通过将一个大函数拆分为几个更简单的函数来减少函数的 MacCabe 数。现在，您如何使用完整的程序来做到这一点？将其拆分为几个更简单的程序/库？是的，我认为这行得通，所以你的想法似乎是合理的。

但这仍然是很多工作。

顺便说一句：这可能是我的烦恼，但我不认为 LoC 的数量与复杂性有很大关系。除了代码行数之外，LoC 是一个非常糟糕的指标。