什么是函数的最佳最大长度？

Question

函数长度会影响程序员的工作效率吗？如果是这样的话，为了避免生产力损失，什么是好的最大线数？

由于这是一个高度固执己见的话题，请用一些数据来支持这一说法。

Answer 1

自从我在1970年开始这个疯狂的拍子，我已经看到了一个模块，它确实需要一个以上的打印页(大约60行)。我见过很多更长的模块。

因此，我已经编写了更长的模块，但它们通常是大型有限状态机，编写为大开关语句。

部分问题似乎是，这些天来，程序员并没有被教导如何模块化。

最大限度地浪费垂直空间的编码标准似乎也是问题的一部分。(我还没见过一位读过温伯格's“"计算机编程心理学”的软件经理。温伯格指出，多项研究表明，程序员的理解本质上仅限于程序员在任何特定时刻所能看到的内容。如果程序员不得不滚动，或翻一页，他们的理解就会明显下降:他们必须记住和抽象。)

我仍然相信，从第四中获得的大量文档丰富的程序员生产力的提高是由于源代码的第四个“块”系统:模块严格限制在16个字符的绝对最多16行。你可以无限地考虑因素，但在任何情况下都不能写17行例程。

Answer 2

合适的尺寸是多少，真的？

这取决于你使用的语言，但总的来说(以及我个人的品味)：

• 理想情况下，少于25行。
• 可接受，少于35行。

如果是更多的话，那我需要稍后再谈一谈，然后再重新工作。

但实际上，当你需要交付某件东西的时候，它需要的任何尺寸，如果你把它们像那样吐出来就更有意义了，有时甚至可以让人在发货前更容易进行审查。(但仍会稍后再谈)。

(最近，我的团队在我们的代码库上运行了一个程序:我们发现类有197种方法，另一种只有3种方法，但其中一种是600行。可爱的游戏:两个邪恶中最糟糕的是什么？)

为了得到更多禅宗的回答..。一般来说，引用一两个伟人的话被认为是一种很好的实践(TM)，下面是这样说的：

每件事都应该尽可能简单，而不是更简单。 - 一个。爱因斯坦 完美终于实现了，不是在不再有任何东西可加的时候，而是在不再有任何东西可以带走的时候。 - 一个。圣埃克苏里

--关于评论风格

的增编

作为这方面的增编，你的职能应该有明确的名称来解释它们的意图。关于评论，我通常不会在函数中发表评论：

• 评论说“为什么？”
• 密码说“怎么做？”。

每个函数顶部的注释块(需要解释)就足够了。如果您的函数很小，并且函数名称足够明确，那么您只需要说明您想要实现什么以及为什么。我只对某些语言中的字段使用内联注释，或者在不明确意图的情况下，对违反25-35行规则的函数使用块开始。当出现异常情况时，我在代码中使用块注释(例如，不需要或不想做任何事情的catch块应该有一个注释说明原因)。

有关更多信息，请阅读我的回答 on 注释代码的样式和建议

Answer 3

在我看来，每个功能都应该尽可能小。每个函数应该只做一件事，并且做得很好。这并不能真正回答最大长度的问题，但更多的是我对函数长度的感觉。

用鲍勃叔叔，“抽离，直到你不能再提取.提取直到你掉下来。“的话