根据您的经验，对于Java中的一个类来说，太多的代码行太多了，有用的经验法则是什么？甚至接近用于特定类和不应该使用的真实标准。应该根据适当的OOP原理（封装等）来设计类。就是说，经验法则可以为重构考虑提供一个有用的起点（例如，“嗯，此类有> n行代码；它可能不可读，并且在封装方面做得很差，所以我可能想看看是否应该可以在某个时候重构”）。 br />这是一个与每个功能的行有关的，不可重复的问题。
#1 楼
一些有趣的指标：
junit fitnesse testNG tam jdepend ant tomcat
----- -------- ------ --- ------- --- ------
max 500 498 1450 355 668 2168 5457
mean 64.0 77.6 62.7 95.3 128.8 215.9 261.6
min 4 6 4 10 20 3 12
sigma 75 76 110 78 129 261 369
files 90 632 1152 69 55 954 1468
total lines 5756 49063 72273 6575 7085 206001 384026
我使用FitNesse作为基准，因为我与编写它有很多关系。在FitNesse中，平均班级长77行。没有一个超过498行。标准偏差为76行。这意味着绝大多数班级少于150行。甚至具有超过5000行的一类的Tomcat，大多数类也少于500行。
鉴于此，我们可以使用200条线作为保持低于线的好指导。
评论
如果班级只有一个职责，那么超过200-500行的机会就很小。通常具有“内部类”的人来处理其他相关职责。例如，Tomcat 5000+线类实际上可能是1个主类和12个内部类。在Java中有请求处理程序之类的情况并不罕见。
–贝琳·洛里奇（Berin Loritsch）
2011年4月11日12:43
真的如何获得这些指标？只是想知道
–Sнаđошƒаӽ
15年7月31日在9:41
我通常更倾向于在与函数有关的链接问题上回答这个问题：programmers.stackexchange.com/a/9452/100669 LOC是无关紧要的，只是作为一个非常普遍的经验法则，只是开始怀疑是否能够进一步分解事物。我同意嵌套类的事情。但是，500可能更接近一般警告信号。
–装甲危机
15年7月31日在13:17
@Sнаđошƒаӽgithub.com/AlDanial/cloc
– firephil
19年3月29日在22:20
#2 楼
对我来说，在这种情况下，代码行无关紧要。这是我来更改此类的各种原因的全部原因。如果我想更改验证个人的规则时来上课，我不想来到同一个班级来更改验证订单的规则，我也不想来这里来更改我保留人员的位置。找到超过200行的课程。出于有效的原因，它们会发生，但很少见。因此，如果您正在寻找一个危险信号指标，那么这并不是一个不好的起点。但要把它作为准则，而不是规则。
评论
200个大概是正确的感觉。就像你说的，虽然不是你首先要担心的事情。
–史蒂夫
2011年4月8日在17:37
关于Java的另一件事是，在计算LOC时，我会忽略getter / setter方法。
–MrFox
13年2月7日在16:12
@MrFox：我不同意。如果您的班级有足够的获取器和设置器来偏移LOC数据，则在“该班级做得太多吗？”中，这与之相反题。但是，作为一种折衷，出于对此类方法过多的考虑，我愿意让NetBean getter / setter方法的行数少于1行/行。
–布赖恩
13年7月12日在19:42
#3 楼
对不起，但令我惊讶的是，许多答案都表明它“并不重要”。一个班级多少行非常重要。为什么？在编写良好的Java代码时考虑这些原则...可测试性
内聚力
耦合
可理解性
类很多其中的行很可能会违反所有这些原则。
对于那些说过“没什么大不了”的人...尝试并理解一个有5000多行的课程吗？还是要修改它？如果您说这很有趣，那么您对疼痛有一种奇特的亲和力...
我的评论是基于阅读和研究马丁·福勒，约书亚·布洛赫和米斯科·赫韦里等作家的。他们是编写优秀Java代码的理想参考资源。他们。
评论
我认为每个人都同意5000+通常不是一个好兆头（不计算嵌套类的数量），但是他们觉得这更多的是副作用，而不是实际的问题。当然，有些人过于冗长，仅使用过多的行来声明和初始化变量等，因此他们必须停止这种行为。这确实使其可读性降低。但是，如果涉及到类结构，那么问题就不在于LOC本身。事实是，有人一开始并没有很好地分解事情，而LOC就是这样做的副作用。
–装甲危机
15年7月31日在13:36
关键是，一个班级应该具有很高的凝聚力和明确的责任感，这意味着班级通常不会增长得那么大。但是，如果一个类经过精心设计，但仍然有5000余行代码，则它无法帮助任何人将其拆分为多个较小的紧密耦合类。
–雅克B
2015年12月4日在10:51
您只是随意选择了1000。为什么不选择500？还是2000？
– gshauger
20-04-22在22:24
阅读和理解其中包含50行以上代码的100个类有多少乐趣？
– gnasher729
20-04-25在8:51
@ gnasher729不好玩...就像阅读/理解意大利面条代码的5K行;）
– Zack Macomber
20 Apr 27 '13：30
#4 楼
这取决于复杂度，而不是行数。我编写了大笨拙的例程，这些例程很容易理解，只完成了一件事情并且做得很好，但是继续进行了数百行。我写了相当短的函数，这些函数很难理解（和调试）。这也可能是一个警告信号。我没有足够的数据可用，但是我建议您查看一些可以在您的商店中做有用的事情的不错的代码，并以此为基础。当然，您应该查看最长的类和最大的API。
评论
+1：不要测量线条之类的哑巴。循环复杂性和特征计数（方法数量）使线条更有意义。
– S.Lott
2011年4月8日在17:47
是的，没有。行数过多通常是设计不良的征兆，因此该类可能需要重构的危险信号。
– jwenting
2011年4月8日在20:10
@jwenting是的，这就是我的意思。我知道很多行！=需要重构，但由于设计不良，几乎所有我正在使用的类都需要重构，因为很多行都如此。
– Michael McGowan
2011年4月8日在20:29
#5 楼
如果类做了太多不同的事情，则代码行太多。本质上，如果您遵循类的“单一职责”原则，则类的增长将受到限制。关于物理限制，您可以拥有（来源：类文件格式Java5）：65,536个常量，所应用的接口，字段，方法和属性-每个。注意：您将用完恒定空间，然后再用完其他任何项目。注意2：属性是类文件的构造-不要与'@Attribute'标记混淆（即调试信息和字节码存储为方法的单独属性）。
每个方法可以是4GB（32位）生成的字节码。注意：1.5版之前的Java版本只能为每个方法生成64KB（16位）字节代码。如果您坚持单一责任原则，那么您的类文件将是正确的大小。
评论
+1为单一责任：） @Berin您是否在软件中严格执行此操作？
– Aditya P
2011年4月8日在18:03
是。诀窍是以合理的方式划分职责。
–贝琳·洛里奇（Berin Loritsch）
2011年4月8日在18:17
嗯，好旧的64KB边界。不错的石蕊测试，以查看您的JSP是否过于复杂，因为它们对所有静态html都转换为具有许多println语句的单个方法：）
– jwenting
2011年4月8日在20:43
从Java 5开始，他们已将其增加到4GB。现在不用担心。
–贝琳·洛里奇（Berin Loritsch）
2011年4月8日在21:42
#6 楼
正确答案是42。开个玩笑。实际上，每个类的建议最大行数是2000行。
自1999年以来的“ Java代码约定”就是这样表示的：
超过2000行的文件很麻烦，应该避免。
自从Java发明以来，就一直遵循Sun / Oracle编码约定，
我发现每个类的行的经验法则是合理。
您的Java代码中有99％应该符合...如果超过2000，
在顶部放置一个TODO表示该类需要工作。
相反，当程序员创建太多小的
小类，而每个类中几乎没有真正的功能时，情况就相反了。忽略关于“ Favor Composition”的建议，程序员创建了数百个继承类，这些类创建的复杂对象模型要比大型类问题（至少通常使用相关类名保留功能）严重得多。
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043
评论
实际上，大多数都是评论@LluisMartinez
– Xtreme Biker
17年7月14日在12:01
我强烈不同意2000。每堂课的注释（注释）不得超过200行。
– Nikolas Charalambidis
19年1月24日在14:45
#7 楼
干净的代码：类应该很小！
类的第一个规则是它们应该很小。类的第二个规则是，它们应该小于该类。不，我们不会在“功能”一章中重复相同的文本
。但是与函数一样，在设计类时，
的主要规则是较小的规则。与功能一样，
我们当前的问题始终是“有多小？”
**使用这些功能，我们可以通过计算物理线来测量尺寸。对于类，我们使用不同的度量。我们计算责任。**
班级的名称应描述班级履行的职责。实际上，命名
可能是帮助确定班级人数的第一种方法。如果我们不能为课程派生一个简洁的名称，则该名称可能太大。类名越模糊，
承担的职责就越多。例如，类名包括狡猾的单词
（例如Processor或Manager或Super）经常暗示不幸的是
职责的聚集。
然后：
确保您的方法只做一件事。
然后确保该类没有太多的责任。
您将得到一个a类可管理的大小。
评论
如果您的答案上方的“清洁代码”是指罗伯特·C·马丁（Robert C. Martin）的书（确实如此），那么我必须说您和我有共同点；那本书使我想到了这个问题。我认为这个答案说明了一切
–Sнаđошƒаӽ
15年7月31日在9:49
#8 楼
行数对于班级质量来说是一个很差的指标。对我来说，我喜欢研究（如其他人所提到的）公共方法以及任何公开的属性（我想是Java中的公共获取器/设置器）。如果我不得不突然想出一个数字来吸引我的注意力，那我会说每个数字都超过10个。确实，如果它的属性或方法超过5个，我会看一下并经常找到重构的方法，但是10个以上的值通常是一个警告信号，表明某些东西很可能暴露得很差。完全是另一回事，但是私有方法和字段对我来说很少有气味，因此，如果它们对行数做出了很大贡献，那么我可能不会那么担心。至少，它表明很可能没有远距离操纵该对象的上帝控制器，这是一个非常有问题的设计问题。
#9 楼
尝试使用更好的指标。ABC指标就是一个例子。它更多地是衡量代码正在执行的工作量而不是代码有多少。
评论
我看过超过一千行的类，我认为没有“太多”之类的东西。当它不再编译时太多了。严重的是，当班级做太多不同的事情时，它太多了。
经验法则变成最大值，这变成策略，然后变成分歧。避免数字。计数和度量不是确定职责分配是否正确的理想方法。
大约与一根弦的正确英寸数相同。
一个具有30票的问题，共阅览了约24,000次，有10个答案（总和）〜75票。 “主要基于意见而关闭”欢迎进行堆栈交换：） SE文化中的某些方面需要改变...