Code metrics have been widely used to estimate software maintenance effort. Metrics have generally been used to guide developer effort to reduce or avoid future maintenance burdens. Size is the simplest and most widely deployed metric. The size metric is pervasive because size correlates with many other common metrics (e.g., McCabe complexity, readability, etc.). Given the ease of computing a method's size, and the ubiquity of these metrics in industrial settings, it is surprising that no systematic study has been performed to provide developers with meaningful method size guidelines with respect to future maintenance effort. In this paper we examine the evolution of around 785K Java methods and show that developers should strive to keep their Java methods under 24 lines in length. Additionally, we show that decomposing larger methods to smaller methods also decreases overall maintenance efforts. Taken together, these findings provide empirical guidelines to help developers design their systems in a way that can reduce future maintenance.
翻译:用于估算软件维护努力的代码测量标准已被广泛用于估算软件维护努力, 通常使用计量标准来指导开发者减少或避免未来维护负担的努力, 大小是最简单和最广泛使用的测量标准, 大小衡量标准很普遍, 因为大小与许多其他通用测量标准( 如麦凯布复杂程度、可读性等) 有关。 由于计算方法的大小容易,而且这些测量标准在工业环境中是普遍的, 令人惊讶的是, 没有进行系统的研究, 以便为开发者提供未来维护努力的有意义的方法大小指南。 在本文件中, 我们审查了785K Java方法的演变情况, 并表明开发者应努力将其爪哇方法保持在24行以下。 此外, 我们表明, 将更大的方法分成较小的方法也减少了总体维护努力。 这些研究结果共同提供了经验性指南, 帮助开发者设计其系统, 从而减少未来的维护。