我想开始衡量 Michael Feathers 所说的代码的动荡，即churn vs.complexity。
为此，我需要测量 C++ 或 Java 文件的复杂性。所以我找到了几个测量圈复杂度（CC）的工具。他们每个人都在功能或方法级别上很好地衡量了 CC。但是，我需要一个文件级别的指标，而他们在那里做得不太好。一个工具只返回文件中所有方法复杂度的平均值，而另一个工具将整个文件视为一个巨大的方法，即它计算整个文件中的所有决策点。
所以我做了一些研究，发现 McCabe 仅根据模块来定义 CC——他们将模块定义为函数——而不是文件（参见本演示文稿的幻灯片 20 和 30 ）。我认为这是有道理的。
所以现在我只剩下试图弄清楚如何表示文件复杂性了。我的想法是我应该只使用该文件的最大方法 CC。
关于这种方法或任何其他建议的任何想法？
谢谢！
肯
几年前我也有同样的问题。我以以下方式回答了它，它对我来说非常有效：
最小化复杂性的目的是提高可维护性。圈复杂度是逻辑复杂度的指标，你是对的——它适用于最小的“单元”，即函数。可以导出“汇总”指标，例如总/最大值/最小值/等，但当涉及圈复杂度时，它们很少显示有用的东西。我尝试使用“汇总”指标来比较 2 个代码库，但得出的结论是，只有圈复杂度的分布图在这里才真正有用。
那么，对于更大的单元/抽象级别（如文件/组件/子系统），什么可以用来表示可维护性级别？我发现第一个指标是代码行中单位的大小。如果您限制文件的大小，例如 1000 行，并限制文件中每个函数的圈复杂度，您将拥有相对“简单”的文件，因为它是“小”并且仅包含“简单”函数。您可以包括或排除注释/空白行或仅计算语句或仅计算可执行行...
但是，我得出的结论是，在这个特定的应用程序中它并不重要。只需限制一些“大小”指标，它就会在大多数情况下达到目的。稍后您可能会考虑限制每个组件/子系统的代码总行数。它将具有相同的效果 - 组件是“简单”的，因为它包含“少量”“简单”文件。
你提到的帖子非常好。它可以扩展到更广泛的指标，通常称为“可维护性指数”。如果函数很复杂、文件很大并且经常更改、测试覆盖率很小等等（在这里添加您认为定义可维护性的任何内容），则该索引非常高。我知道，这是找到重构热点的最佳方式……
免责声明：我正在照顾执行用例场景的Metrix++工具，我在上面解释过。