java方法长度不超过几个字符方法长度不超过多少行

转载

架构设计师 2024-03-07 07:59:07

文章标签 java方法长度不超过几个字符 python 机器学习 java 编程语言 文章分类 Java 后端开发

关心编写好的代码的人经常会提出一个问题：方法或函数，类，包或任何其他代码块的正确大小是多少？
在某些时候，任何一段代码都可能太大而无法正确理解，但是太大又太大了？它从方法或功能级别开始。史蒂夫·麦康奈尔（Steve McConnell）在《代码完成》中说，一种方法或函数的理论最佳最大限制是可以在一个屏幕上显示的行数（即，开发人员一次可以看到的行数）。然后，他继续进行1980年代和1990年代的参考研究，发现功能的最佳结合点在65行到200行之间：这种大小的例程开发成本较低，每行代码的错误更少。

但是，在超过200行的某个点上，您会进入一个危险区域，在该区域中，代码质量和易理解性将崩溃：无法测试且无法安全更改的代码。最终，您最终遇到了迈克尔·费瑟斯（Michael Feathers）所说的“ 失控方法 ”：这些例程长数百行或数千行，并且不断被更改，并且不断变得更大和更可怕。

帕特里克·杜博伊（Patrick Duboy）对方法的长度进行了更深入的分析，并指出2002年以来的一项更现代的研究表明，具有较短例程的代码总体上具有较少的缺陷，与大多数人的直觉和经验相匹配。

越小越好

鲍伯马丁采取的想法，“如果小是好的，那么小的一定会更好”，以在极端的清洁守则：

“功能的首要规则是它们应该很小。 功能的第二个规则是它们应该小于该值。 函数的长度不能超过100行。 功能几乎不应超过20行。”

马丁承认“这不是我可以证明的主张。我无法提供任何表明很小的功能更好的研究参考。” 因此，就像软件开发社区中的许多其他规则或最佳实践一样，这是某人根据其个人经验编写的代码进行的定性判断-不仅仅是一种美学论据，甚至是一种道德论据，而不是经验性论证。风格重于实质。

相同的“精益求精”指南适用于类，包和子系统–系统的所有构建块。在Code Complete中，一项从1996年开始的研究发现，具有更多例程的类具有更多缺陷。与清理代码一样，类的功能也应“小于小于”。有人建议200行是一门课的一个很好的限制 –不是一种方法，或者是50-60行（在Ben Nadel的“ 徒手健身”练习中），并且一堂课应包括“少于10条”或“不超过10条”超过20英寸的方法。著名的C3项目（极限编程的诞生地）平均每个班级有12种方法。每个包的类数量不得超过10个。

PMD是一种静态分析工具，可帮助突出显示代码结构和样式中的问题，它为代码大小限制定义了一些默认值：每个方法100行，每个类1000行，每个类10个方法。类似的工具Checkstyle提出了不同的限制：方法中的50行，类中的1500行。

30法则

寻找这样的指导方针使我进入了Martin Lippert和Stephen Roock的大型软件项目重构中的“ 30条规则”：
“如果一个元素包含30个以上的子元素，则很可能存在严重的问题”：

方法的平均行数不应超过30（不计算行空间和注释）。
一个类平均应包含少于30个方法，从而导致多达900行代码。
一个程序包不应包含超过30个类，因此最多包含27,000个代码行。
应当避免包含30个以上软件包的子系统。这样的子系统最多可以计数900个类，最多可以包含810,000行代码。
因此，具有30个子系统的系统将拥有27,000个类和2430万个代码行。

看起来像什么？以100万个NCLOC的庞大系统为例。这应该分解为：

30,000种以上的方法
1,000多个课程
30多个包裹
希望有多个子系统

现实世界中有多少个系统看起来像这样或接近这个样子-特别是已经存在了几年的大型系统？

您应该如何使用它们？

使用代码大小作为此类规则的基础很简单：易于查看和理解。太简单了，许多人会争辩：当代码太大时，更好的指标是循环复杂度或某种其他代码质量度量。但是最近的一些研究表明，代码大小实际上是复杂性和质量的有力预测指标 –

“复杂性指标与代码行高度相关，因此，更复杂的指标不会提供无法通过代码行进行简化而无法测量的更多信息”。

在制作软件的 “超越代码行：我们是否需要更多复杂性度量标准”一书中，作者甚至说，应始终将代码行视为缺陷预测，开发和维护模型的“首要指标” 。

认识到简单的大小调整规则是任意的，您应该使用它们吗？

我喜欢粗略且易于理解的经验法则的想法，在编写代码或查看代码并决定是否应该对其进行重构时，您可以始终牢记在心。准则（如30条规则）的真正价值在于查看代码并确定风险和成本时。

但是在编写每段代码时以繁重的方式执行这些规则是愚蠢的。当您要在某个方法中编写第31行时，您不想停下来–它将使检索工作变慢。强迫所有人破坏代码以适应任意大小限制将使代码变得更糟，而不是更好-结构将由短期决策支配。

正如Jeff Langer在他的章节中所讨论的那样，该章节讨论了Ken Beck的“简洁代码中简单设计”的四个规则：

“我们的目标是保持整体系统的小型化，同时保持功能和类的小型化。 但是请记住，此规则是“简单设计”四个规则中最低的优先级。 因此，尽管保持低的类和函数计数很重要，但是进行测试，消除重复并表达自己更为重要。” 有时需要超过30条线（或20或5条线或任何截止线）才能完成连贯的工作。更加重要的是要谨慎地提出正确的抽象和算法，并编写清晰的代码-如果切入尺寸的准则有助于做到这一点，请使用它。如果没有，那就不要打扰。

参考： 30条规则–什么时候方法，类或子系统太大？来自JCG合作伙伴 Jim Bird在Building Real Software博客上的介绍。