“推荐”文件的长度和线宽[关闭]

我很好奇是否有人知道有信誉的来源给出的关于给定文件的最大代码行数的建议。例如，Google的Closure Linter建议每行不应超过80个字符。

文件应足够短，以使您可以找到任何函数或方法，而无需前后滚动多次以寻找该函数或方法，也不必记住搜索字符串。我使用的指标是我在文件中查找代码而不是读取代码所花费的时间。如果这变得明显，是时候重新分区文件或类了。

一个基本代码块的合适大小在宽度和高度上都足够短，这样您就可以在组代码检查期间投影出其内脏，并使其完全适合而字体又不会太小，以至于后面的家伙会议室看不懂。如果在移动设备或平板电脑上都只有电话来解释一些代码时，此大小也很有帮助。

没有这样的事情，如果有的话，那将高度依赖于您使用的语言（例如，在汇编程序与C＃或Java中做同样的事情）。

对于高级语言，您可以查看此 SO讨论。对于Java / C＃，鲍勃·马丁（Bob Martin）建议最大为每个方法 10-20行。没有关于文件的讨论，因为它无关紧要，并且取决于类应该做什么。

关于每行80个字符的限制-这是打孔卡时代的倒退。话虽这么说，但当行长过长时，可读性会受到影响。

文件和行的长度是对复杂性的次要影响的度量，因此高度可变。您应该针对的是没有不必要复杂性的代码，没有一定的最大行数。

长文件倾向于指示方法，子例程或类过于复杂（做太多事情，未充分考虑因素等）

较长的线条倾向于表示表达式过于复杂。

它们是表明潜在代码问题的气味，而不是明确定义的目标指标。

行长应使您不必滚动屏幕即可看到整条线。这取决于显示器的尺寸和分辨率。

如果适合一个屏幕，则方法和功能最好。

文件不要太长。最好是简短的文件，易于理解的类和实现。
一旦我从事的项目有10 klines文件。就像读一本非常复杂的书。我是否需要告诉该实施造成了多少问题？

80个字符！

我记得当我做COBOL时曾经看过计费程序的源代码文件，大约80 页。当然，我看不到这是很常见的做法，但是80个字符同样荒谬。

从类大小的角度来看，如果您尝试将此建议应用于具有约80个属性和20个左右方法的典型Customer类，则必须将该类分解为其他几个类，并使代码确实非常混乱。

我尝试使类和方法简短，但是不必担心行长。在如今的宽屏和长标识符的今天，我认为80个字符太少了。破坏语句需要花费一些工作，以使它们易于阅读，并且限制在80个字符以内，它经常发生。我认为每行120或130列比较合理。