我想开始测量Michael Feathers所称的代码紊乱,即
churn vs. complexity.

为此,我需要测量C或Java文件的复杂性.所以我发现了一些测量圈复杂度(CC)的工具.它们各自在功能或方法级别上很好地测量CC.但是,我需要一个文件级别的度量标准,并且它们在那里做得不好.一个工具只返回文件中所有方法复杂度的平均值,另一个工具将整个文件视为一个巨大的方法,即它计算整个文件中的所有决策点.

所以我做了一些研究,发现McCabe仅在模块方面定义CC – 并且它们将模块定义为函数 – 而不是文件(参见this presentation的幻灯片20和30).而且我认为这是有道理的.

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

有关该方法或任何其他建议的任何想法？

谢谢！

肯

最佳答案 几年前我有同样的问题.我用以下方式回答了它并且它完美地起作用并且对我有用：

最小化复杂性的目的是提高可维护性.循环复杂性是逻辑复杂性的指标,你是对的 – 它适用于最小的“单位”,即功能.可以推导出“总结”指标,例如总计/最大/最小/等,但是当涉及圈复杂度时,它们很少显示有用的东西.我尝试使用’summary’指标来比较2个代码库,但得出的结论是,只有圈复杂度的分布图才真正有用.

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

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

你提到的帖子非常好.它可以扩展到更广泛的度量,通常被称为“可维护性指数”.如果函数很复杂,文件很大并且频繁更改,测试覆盖率很小等等(在此处添加您认为定义的可维护性),索引非常高.我知道,这是找到重新分解热点的最好方法……

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