测量代码复杂度

最近，开发经理对度量代码质量引起了很多兴趣。 因此，诸如代码审查和分析工具之类的东西在早期识别“技术债务”方面已变得非常流行。

Java有几种工具： Sonar ， JavaNCSS ，Eclipse插件； 以及其他语言：Visual Studio代码分析，PHPDepend等。

什么是技术债务？

在Sonar网站上 ，技术债务是按以下公式计算的成本（工时）：

TD =（解决重复的费用）+（解决违规的费用）+
（评论公共API的费用）+（修复未发现的复杂性的费用）+
（使复杂度低于阈值的成本）

实际上，许多组织都将这一指标作为长期投资。 尽管很难量化，但是减少技术债务可以减少打开的错误的总数，提高代码质量，减少开发人员的启动时间（从而符合Brooks法则），更重要的是减少了所需的人工（小时）数。解决一个问题-一笔不错的投资。

在本文中，我想集中讨论一个称为“代码复杂性”的技术债务因素。

代码本身的复杂度非常“复杂”。 它受许多因素影响，例如：平均层次结构高度，派生类的平均数量，传入耦合，传出耦合，“ if”条件语句的数量等。 让我们简要地讨论一些最重要的指标，以了解这些工具捕获了什么以及如何对其进行了度量。

McCabe圈复杂度（MCC）

您可能以前曾经遇到过这个。 Thomas McCabe于1976年推出了McCabe Cyclomatic Metric（链接到底部的本文）。 它通过一种特定方法（尽管该示例适用于整个程序或子例程）来测量通过某种特定方法的独立路径的数量（取自图论的术语）。 例如，对于没有条件的简单方法，MCC为1。具有许多条件的程序更难遵循，更难测试，因此具有更高的MCC。

MCC公式为：

M = E – N + X

其中M是McCabe循环复杂度（MCC）度量标准，E是边数，N是节点或决策点（条件语句）的数量，X是方法图中的出口（返回语句）的数量。

快速示例：

在此示例中，MCC = 3

下式说明了一种计算MCC的更简单方法。 如果D是程序中的决策点数，则

M = D +1（每个决策点通常具有两条可能的路径）

如前所述，MCC在确定方法的可测试性方面也很有用。 通常，值越高，该方法的测试和维护就越困难和危险。

环复杂性的一些标准值如下所示：

M = D + 1	评估
1-10	风险不大
11-20	中度风险
21-50	高风险
51岁以上	无法测试，极高的风险

关于MCC的最后一句话也适用于其他大多数指标：公式中的每个元素均假定具有相同的权重。 在MCC的情况下，假设两个分支都同样复杂。 但是，在大多数情况下并非如此。 考虑一下仅对一个分支具有代码的if语句，但每个分支被视为具有相同的权重。 而且，即使对于包含许多因素和术语的表达方式，其表达方式也是相同的。 请注意这一点，并准备好（如果您的工具允许您）增加不同分支的权重。 此度量标准称为扩展McCabe复杂性度量标准。

传入耦合（Ca）
传入耦合是依赖于此包中的类的其他包的数量。 该值很好地表明了对该程序包中的类所做的更改将如何影响软件的其他部分。

传出耦合（Ce）
传出耦合是此包中的类所依赖的其他包的数量。 此值指示此软件包对更改其他软件包的敏感程度。

具有高Ca和高Ce的代码很难测试和维护，因此具有很高的复杂度并且非常不稳定。

不稳定度（I）
不稳定性是传出耦合（Ce）与总封装耦合（Ce + Ca）之间的比率，该比率基于以下公式（Ce /（Ce + Ca）），结果为[0,1]。 当I-> 0时，这表示完全独立的最大稳定包。 另一方面，当I-> 1时，这表示完全不稳定的程序包，它没有传入的依赖关系，但依赖于其他程序包。

资源资源

• 用声纳评估您的技术债务
• OO设计质量指标–依赖性分析（PDF）
• 复杂性度量（GDocs PDF）

参考：从我们的JCG合作伙伴 Luis Atencio 反思反思中 测量代码的复杂性 。

相关文章 ：

• 使用FindBugs产生更少的错误代码
• 为什么自动化测试可以提高您的开发速度
• 不执行代码审查？ 你的借口是什么
• Java工具：源代码优化和分析
• 您的代码中有几个错误？

翻译自: https://www.javacodegeeks.com/2011/09/measuring-code-complexity.html