良好做法班线数[关闭](Good practice class line count [closed

我知道，有没有权利回答这个问题，我只是要求你的意见。

我知道，创建与千行代码巨大的类文件是不是一个好的做法，因为它难以维持，也通常意味着你应该检查你的程序逻辑。

在您看来，什么是一类平均线数，让我们在Java中说，（我不知道，如果语言的选择有什么关系，但以防万一...）

Answer 1:

是的，我会说这确实有做的语言，如果仅仅是因为某些语言是比其他人更详细。

一般情况下，我用拇指以下规则：

<300线：细
300 - 500线：合理
500 - 1000线：也许不错，但在重构计划
> 1000行：绝对重构

当然，这真的取决于更多的代码比LOC的性质和复杂性，但我发现这是合理的。

Answer 2:

在一般情况下，行数不是问题 - 一个稍微好一点的度量的公共方法数。但没有正确的数字。例如，公用事业串类可能正确地有数百个方法，而业务水平一流的可能只有一对夫妇。

如果您有兴趣LOC，圈等复杂的测量，我可以强烈建议从源监视器http://www.campwoodsw.com ，这是免费的，主要的语言如Java和C ++的作品，并且是所有的一轮大。

Answer 3:

从雷蒙德的“艺术的Unix编程”

在非数学术语，哈顿的经验结果暗示的最小化可能的缺陷密度，所有其他因素（如程序员技能）等于码200条400的逻辑线之间的最佳平衡点。这个尺寸是独立于语言的使用 - 这大大加剧了在这本书的其他地方给出了最有力的语言，你可以工具编程的建议观察。谨防文生义但是采取这些数字。用于计数的代码系的方法变化显着地根据什么分析师认为逻辑线，和其它偏差（例如是否评论被剥离）。哈顿自己表明作为一个经验法则的逻辑和物理线之间的2倍的转换，这表明400-800物理线路的最佳范围。

来自这里

Answer 4:

更好地衡量像圈复杂度和使用，作为一个标尺。你甚至可以把它贴在你的构建脚本/蚂蚁文件/ etc。

这是太容易了，即使有标准的代码格式，从类的真正复杂断开行代码。

编辑：见这个问题对于圈复杂工具的列表。

Answer 5:

我注重方法和（试图）让他们在20行代码。级长度一般由单一职责原则决定。但我认为，这是没有绝对的指标，因为它依赖于抽象的层次，因此某处300和500之间的线我开始寻找了一个新的责任，或抽象，提取代码。

Answer 6:

足够小，只能做它委以重任。

大到足以做只有它被委以重任。

无多，不会少。

Answer 7:

根据我的经验超过1000条线路上所有的源文件，我会开始想分手。理想的方法应该尽可能在一个画面上。

最近，我开始认识到，消除无用的注释可以与此有很大帮助。我的评论更为谨慎，现在比我20年前当我第一次开始编程。

Answer 8:

答案很简单：不超过250行。

更短的答案：穆。

较长的答案：是对程序的可读性和简洁的？请问类有一个单一的责任吗？代码是否重演？

Answer 9:

对我来说，问题不是LOC。我看是几个因素。首先，检查我的if-else-if语句。如果他们中的很多具有相同的条件下，或导致类似的代码中运行，我尝试重构这一点。然后我看着我的方法和变量。在任何单个的类，该类应该有一个主要功能和仅该功能。如果有变量和方法对不同的区域，可以考虑把这些变成自己的阶级。无论哪种方式，避免有两个原因计数LOC：

1）这是一个糟糕的度量。如果算上LOC您计算不只是排长队，而且还包括空格和使用的意见，尽管它们是相同的路线。你能避免这一点，但在同一时间，你还在计算小线和长行也同样。

2）这是误导。可读性是不是纯粹的LOC的功能。一个类可以是完全可读的，但如果你有一个LOC计数，它违反了，你会发现自己的工作努力，你可以挤尽可能多的行出来。你甚至可能最终使代码的可读性变差。如果你把给变量赋值，然后在方法调用中使用它们的LOC，它比调用这些变量的赋值直接在方法调用本身更具可读性。最好是有5行可读的代码，而不是它凝结成1线的读取代码。

相反，我会看的代码和线路长度的深度。这是更好的指标，因为他们会告诉你两两件事。首先，嵌套的深度会告诉你，如果你的逻辑需要进行重构。如果您正在寻找在if语句或循环嵌套超过2深，认真考虑重构。试想，如果你有嵌套多个级别重构。其次，如果一个线长，它通常是非常不可读。尝试线分离出到几个更可读的行。这可能会破坏你的LOC限制，如果你有一个，但它实际上是提高可读性。