Java中每个类有多少行？[关闭]

根据您的经验，对于Java中的一个类来说，太多的代码行太多是什么有用的经验法则？

明确地说，我知道行数甚至不接近用于特定类中什么应该不使用的实际标准。应该根据适当的OOP原理（封装等）来设计类。就是说，经验法则可以为重构考虑提供一个有用的起点（例如，“嗯，此类有> n行代码；它可能不可读，并且在封装方面做得很差，所以我可能想看看是否应该在某个时候重构”）。

在另一方面，也许您遇到过非常大的类的示例，这些类仍然很好地遵守了OOP设计，并且尽管它们的长度很长，但是它们都是可读性和可维护性的？

这是一个有关每个函数行数的相关，不可重复的问题。

一些有趣的指标：

            junit Fitnesse testNG tam jdepend ant tomcat
            ----- -------- ------ --- ------- --- ------
最多500498 1450 355668668 2168 5457
均值64.0 77.6 62.7 95.3 128.8 215.9 261.6
最小4 6 4 10 20 3 12
Sigma 75 76 110 78 129 261 369
档案90 632 1152 69 55 954 1468
总行5756 49063 72273 6575 7085 206001 384026

我将FitNesse用作基准，因为与编写它有很多关系。在FitNesse中，平均班级长77行。没有一个超过498行。标准偏差为76行。这意味着绝大多数班级少于150行。甚至具有超过5000行的一类的Tomcat，大多数类也少于500行。

鉴于此，我们可以使用200条线作为保持不变的良好指导。

对我来说，在这种情况下，代码行无关紧要。这是所有我要去上这堂课更改它的不同原因的全部。

如果我想更改验证个人的规则时要来上这堂课，我不想来同一堂课来更改用于验证订单的规则，也不想来这儿来修改我的位置坚持一个人。

就是说，如果您以此为目标，那么您很少会找到200行以上的课程。出于有效的原因，它们会发生，但很少见。因此，如果您正在寻找一个危险信号指标，那么这并不是一个不好的起点。但这只是一个准则，而不是一条规则。

对不起，但令我惊讶的是，许多答案都表明它“并不重要”。一个班级多少行非常重要。为什么？在编写良好的Java代码时考虑这些原则。

• 可测性
• 凝聚
• 耦合
• 易懂

其中包含很多行的类很可能会违反所有这些原则。

对于那些说过“没什么大不了”的人……尝试并理解包含5000行以上内容的课程有多有趣？还是要修改它？如果您说这很有趣，那么您对疼痛有一种奇特的亲和力...

我要说的是，任何包含超过1000行的类都至少应受到质疑，它们如何违反上述原则，并可能解析为几个“分支”类。

我的评论基于阅读和研究Martin Fowler，Joshua Bloch和Misko Hevery之类的作者而得出。他们是编写优秀Java代码的优秀参考资源。

下一个家伙（可能会在几年后成为您）帮个忙，并努力编写包含更少而不是更多行的类。

这取决于复杂度，而不是行数。我编写了大笨拙的例程，这些例程很容易理解，只完成了一件事情并且做得很好，但是继续进行了数百行。我编写了相当短的函数，这些函数难以理解（和调试）。

您可能要看的另一件事是一个类中公共函数的数量。那也可能是一个警告信号。

我没有足够的数据，但我建议您查看一些在您的商店中做有用的事情的不错的代码，并以此为基础。当然，您应该查看最长的类和最大的API。

如果类做了太多不同的事情，则代码行太多。本质上，如果您遵循班级的单一职责原则，班级的规模将受到限制。

关于物理限制，您可以拥有（来源：类文件格式Java5）：

• 65,536个常量，应用的接口，字段，方法和属性-每个都有。注意：您将用完恒定空间，然后再用完其他任何项目。注意2：属性是类文件的构造，不要与“ @Attribute”标记混淆（即，调试信息和字节码存储为方法的单独属性）。
• 每个方法可以是4GB（32位）的生成字节码。注意：1.5版之前的Java版本只能为每种方法生成64KB（16位）的字节码。

简而言之，类文件可能比任何人都认为有用的文件大得多。如果您遵循单一职责原则，那么您的类文件将是正确的大小。

正确答案是42。开个玩笑。
实际上，每个类的建议最大行数为2000行。

自1999年以来的“ Java代码约定”就是这样表示的：
超过2000行的文件很繁琐，应避免使用。

自从Java发明以来，就遵循Sun / Oracle Coding约定，我发现每个类的行的经验法则是合理的。您的Java代码中有99％应该符合...如果超过2000，则在顶部放置一个TODO表示该类需要工作。

相反，最糟糕的情况是程序员创建了太多的小类，而每个类中几乎没有真正的功能。忽略对“ Favor Composition”的建议，程序员创建了数百个继承类，这些继承类创建的复杂对象模型要比大型类问题（至少通常使用相关类名保留功能）差得多。

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

清除代码：

班级应该很小！

类的第一个规则是它们应该很小。类的第二个规则是它们应该小于该类。不，我们不会重复“功能”一章中的相同文本。但是与函数一样，在设计类时，较小的原则是首要原则。与功能一样，我们当前的问题始终是“有多小？”

**使用功能，我们通过计算物理线来测量尺寸。对于类，我们使用不同的度量。我们计算责任。**

班级的名称应描述班级应履行的职责。实际上，命名可能是帮助确定班级人数的第一种方法。如果我们不能为类派生一个简洁的名称，则它可能太大。类名越模糊，它承担的职责就越可能。例如，类名包括诸如处理者或管理者或超级之类的狡猾的单词，通常暗示着职责的不合时宜。

然后：

• 只要确保您的方法只做一件事即可。
• 然后确保班级没有太多的责任。

您将得到一班可管理的班级。

行数对于班级质量来说是一个很差的指标。对我来说，我喜欢研究（如其他人所提到的）公共方法以及任何公开的属性（我猜想是Java中的公共获取器/设置器）。如果我不得不在某个时候吸引一个数字来吸引我的注意力，那我会说每个数字都超过10个。确实，如果它的属性或方法超过约5个，我会看一下并经常找到重构的方法，但是超过10个通常表示一个警告信号，表明某些东西很可能暴露得很差。

完全是另一回事，但是私有方法和字段对我来说却很少，因此，如果它们对行数做出了很大贡献，那么我可能不会那么担心。至少，它表明可能没有远距离控制器操纵远处的物体，这是一个相当大的问题设计问题。

尝试使用更好的指标。

ABC指标就是一个例子。它比代码多少来衡量代码正在执行的工作量。

不在您的班级问题域内的任何行都写在该班级之外，则该行所在的班级中的一行太少了。将课程视为主题。你必须掩盖它。尽可能简明扼要是理想的，但是如果需要500线，则需要500线。如果其中有100行涉及另一个主题，则它们属于其他位置。将内部类细分为类中较小的子域是有意义的，但我只会在类外部使用那些在其他地方使用的情况下进行定义。