如何衡量 C++ 或 Java 文件的复杂性？

Question

我想开始衡量 Michael Feathers 所说的代码动荡，即churn vs. complex。

为此，我需要衡量 C++ 或 Java 文件的复杂性。所以我找到了几个测量圈复杂度（CC）的工具。他们都在功能或方法级别很好地测量了 CC。但是，我需要一个文件级别的指标，而他们在那里做得并不好。一个工具只返回文件中所有方法复杂度的平均值，另一个工具将整个文件视为一个巨大的方法，即计算整个文件中的所有决策点。

所以我做了一些研究，发现 McCabe 仅根据模块来定义 CC——他们将模块定义为函数——而不是文件（参见本演示文稿的幻灯片 20 和 30 ）。我认为这是有道理的。

所以现在我要尝试弄清楚如何表示文件复杂性。我的想法是我应该对该文件使用最大方法 CC 。

关于这种方法的任何想法或任何其他建议？

谢谢！

肯

Answer 1

几年前我也有同样的问题。我用以下方式回答了这个问题，它对我来说非常有效：

最小化复杂性的目的是提高可维护性。圈复杂度是逻辑复杂度的指标，你是对的 - 它应用于最小的“单元”，即函数。可以得出“摘要”指标，例如总计/最大/最小/等，但当涉及圈复杂度时，它们很少显示有用的东西。我尝试使用“摘要”指标来比较 2 个代码库，但得出的结论是，只有圈复杂度的分布图在这里才真正有用。

那么，什么可以用来指示更大单元/抽象级别（例如文件/组件/子系统）的可维护性级别？我发现第一个指标是代码行单位的大小。如果限制文件的大小（例如 1000 行），并限制文件中每个函数的圈复杂度，则您将获得相对“简单”的文件，因为它“小”并且仅包含“简单”函数。您可以包含或排除注释/空白行或仅计算语句或仅计算可执行行...

然而，我的结论是，在这个特定的应用程序中这并不重要。只需限制一些“大小”指标，它在大多数情况下都可以达到目的。稍后您可能会考虑限制每个组件/子系统的代码总数。它将具有相同的效果 - 组件是“简单”的，因为它包含“少量”的“简单”文件。

你提到的那个帖子非常好。它可以扩展到更广泛的指标，通常称为“可维护性指数”。如果函数很复杂，文件很大并且经常更改，测试覆盖率很小，等等（在这里添加您认为定义可维护性的任何内容），则索引非常高。我知道，这是寻找重构热点的最佳方法......

免责声明：我正在寻找执行用例场景的Metrix++工具，我在上面解释过。