如何测量C++；还是Java文件的复杂性？

我想开始测量Michael Feathers所说的代码湍流，即

这样做，我需要测量C++或java文件的复杂性。所以我找到了两个工具来测量圈复杂度（CC）。它们在函数或方法级别都能很好地度量CC。然而，我需要一个文件级别的度量，而它们在那里做得并不好。一个工具只返回文件中所有方法复杂性的平均值，另一个工具将整个文件视为一个巨大的方法，即，它统计整个文件中的所有决策点

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

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

对这种方法或其他建议有何想法

谢谢

---

肯几年前我也有同样的问题。我用以下方式回答了这个问题，它非常适合我：

最小化复杂性的目的是提高可维护性。圈复杂度是逻辑复杂度的指标，你是对的——它应用于最小的“单元”，即函数。可以导出“摘要”度量，如total/max/min/etc，但当涉及圈复杂度时，它们很少显示有用的内容。我试图使用“摘要”度量来比较两个代码库，但得出的结论是，这里只有圈复杂度分布图才真正有用

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

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

你提到的那篇文章很好。它可以扩展到更广泛的度量，通常称为“可维护性指数”。如果一个函数很复杂，文件很大，并且有频繁的更改，测试覆盖率很低，等等，那么索引就会很高（在这里添加您认为定义可维护性的内容）。这是最好的方法，我知道，找到热点重新分解

---

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

您可能应该前往。StackOverflow是针对具体问题的。

几年前我也有同样的问题

这是Metrix++的起点吗？它还保持着吗（好像主页是新的）？这不是起点，我在需要的时候扩展了。过去两年我没有添加新功能，但我只是在它工作时使用它，并做我需要它做的事情。