每个函数是否有最佳的代码行数？[关闭]

函数不仅用于最大程度地减少代码重复，而且还用于将长函数拆分为较小的函数以提高可读性，并使代码具有自注释性。但是，这种增益与每个函数或方法的LOC数量并不成反比；否则，我们将拥有大量功能，所有功能仅包含一行或两行代码。

这使我想知道：每个功能是否存在最优数量的LOC？如果是这样，那是什么，它在语言之间是否有差异？

我要使用的标准不是行数，而是每个函数只能做一件事并且做得很好。

一个古老的经验法则是，功能应该在屏幕上完全可见，而无需滚动。

基本思想是，如果您不能一次查看整个功能，则该功能过于复杂，您应将其拆分为更多基本部分。

虽然此规则非常实用且有用，但正式规则是您应仅在函数中保留一个逻辑步骤。函数仅执行基本工作，如果您可以将工作划分为更多基本部分，则必须将函数拆分。

空无一人。

屏幕越来越大，字体越来越小。当人们的拇指大小不同时，经验法则不能很好地发挥作用。

简明扼要。如果您的函数执行多项操作，则最好将其分解为较小的部分。

Smalltalk具有减小方法大小的不寻常方法。编写代码时，将其编写在名为“浏览器”的小部件中。浏览器有两个主要部分，水平划分。您的代码位于下半部分。

默认情况下，浏览器不是很大。您可以先放入5或6行，然后再开始滚动。滚动当然有点令人讨厌。

因此，在Smalltalk中，环境“鼓励”您编写简短的方法，最长不超过6行。（通常足够； Smalltalk是一种非常简洁的语言。）

方法中理想的代码行数是可变的。基本上，您只想编写足够的代码来执行在函数定义的上下文中需要执行的操作。我认为这是一种“ 单一责任原则”，仅适用于方法而不是类。

如果方法具有很多逻辑，并且需要完成许多步骤，则可以将方法分解为几个离散的步骤。这些步骤中的每一个都将根据需要提取到新方法中。

“否则，我们将拥有大量的功能，所有这些功能仅包含一行或两行代码。”

每种方法做的越少，定义就越容易，并且更易于理解和管理。如果需要，拥有数百种方法没有错。而且，与我之前提到的SRP保持一致，当方法被拆分成更小和更易于管理的片段时，提取新类变得更加容易。

答案当然是42。

重要注意事项：任何功能都不能违反SRP，否则您将不得不面对spanisch的询问。

一些提示如何减少行数：

• 是否有注释标记各个部分？这些部分应该是函数。
• 工厂/制造商外部是否有if-else链或switch语句？您的设计可能需要一些更好的设计模式来帮助您分担责任。
• 您的功能易于测试吗？使您的功能易于测试，它们会崩溃。
• 它很复杂，只有一片土地吗（1000个线怪兽）？进行废品重构-这是重构，不要保存它，以期了解有关代码职责的知识。

以下是一些线索：

• 如果您在编写说明功能目的和用法的注释时遇到麻烦，则该时间太长。

• 如果您很想编写注释来解释函数中一段代码的活动，则该函数太长。

• 如果要从另一个函数粘贴代码，那么它们都太长了（将该代码提取为一个单独的函数）。

• 如果您需要一种编码约定来将类数据成员与局部变量分开，则该函数过长，并且该类具有太多的成员。

• 如果您在阅读功能时需要记笔记，则时间太长。

具有“音调”的功能（每个音调只有一两行）不一定是一件坏事。我发现这些小功能的重用远远超出了我最初的预期。