方法重构

Question

在您需要更好地设计之前，方法可以使用多少行代码进行良好的设计？

Answer 1

代码行是用于重构的不完整指标。 Cyclomatic Complexity应与LOC结合使用，作为何时重构的合适标准。

一个体面的指导方针是

  

LOC > 80 || CC > 10 == "Time to refactor"

您可能会遇到Cyclomatic Complexity＆gt; 10，在你达到80行代码之前很久。

当然，还有一些其他指标需要考虑：

1. 传入耦合：有多少方法依赖于此方法
2. 传出耦合：此方法依赖多少种方法
3. 否。参数
4. 否。使用Varialbes

你可以深入探讨，但所有这一切都说明，确定何时重构不能用一条全面的规则来决定，比如 “任何方法都不能超过40行！”

Answer 2

没有公认的规则。它应该尽可能简单易读。如果这意味着占用10行的5行并将它们放入自己的方法中，那就这样吧。但有时候，使用50行方法可能会很好。在6个月的时间里做你认为最能理解的事情。

Answer 3

取决于该方法的作用。在编写太少的方法和太多的方法之间有一个很好的界限，其中大部分都是个人品味的问题。

我的意见：

• 对于一种方法，50行太长。我认为比这更短的方法通常也太长，但这是我方法长度的最高阈值。
• 应编写方法，使其不止一次使用。不要仅仅为了缩短现有方法而进行重构;重构可以使其他方法受益的可重用方法。

在需要重新设计方法之前，方法可以拥有的代码长度没有任意限制。但是，通常情况下，如果方法感觉“太长”，则表明您做错了。

Answer 4

不作为规则，但作为一种启发式方法，当一个方法超过25行时，我给它一次，看看我是否可以将它分解为更简单的组件。

这并不是说超过25行的方法从未设计得很好，或者较短的方法总是比较长的方法好。这只是一个很好的启发式方法。

Answer 5

尽可能多地逻辑清晰地执行方法执行的单个任务。

说真的，没有标准。通常人们喜欢能够在他们的显示器上的一个页面内看到整个方法，因此这是一件需要考虑的事情。但行数并不是逻辑问题的主要指标。太多的开发人员对代码进行了模糊处理，并且通过尽可能少的代码使得未来的支持变得更加困难。

在单个方法中，1000行代码没有任何内在错误，如果这是逻辑上和清楚地执行该任务所需要的。这种情况很少见，并且长期通常重新分解符号的方法，但这是可能的。 本来就是错误的，1000行意大利面条代码都做了不同的事情，并在一个方法中以奇怪的方式进行交互。行数不是问题。

Answer 6

代码行是一个度量标准，但另一个要查看的是代码路径。每个if，和，或循环等使函数更复杂。您可以拥有非常简短的复杂功能，并且可以使用简单易懂的功能。使用它时重构效果很好，降低了复杂性，而不一定是代码行。

例如：

if (color.r == color.g && color.r == color.b)
    if (color.r > 128)
       newColor = color.White;
    else
       newColor = color.Black;

VS

if(isGray(color))
   newColor = thresholdGray(color)

意图更清晰，路径数量减少。

Answer 7

确实，LOC是一个糟糕的指标，因为它与你真正感兴趣的属性（设计质量）没有很好的相关性。但它作为衡量指标的巨大优势 - 以及如此广泛使用和讨论的原因 - 当然是多么容易衡量。那不是纯粹的懒惰;只需百分之一的努力，你就可以得到 - 好吧，可能是更有意义的指标价值的20％或30％。您只需浏览一个方法或类的最后一行，然后评估LOC指标。你可以看看滚动条的高度，并有一个很好的主意。

有真正的LOC限制是有意义的 - 太多无法放在显示器上或文本页面上，实际上太多了，尽管简单和凝聚力。

我喜欢非常简短的方法。单行很棒。当一个方法开始进入两位数LOC时，它会发出痒声。如果它是30或更多，那很痛苦。继续使用LOC;只是将其弱点理解为度量标准，并了解存在哪些更好的指标（例如圈复杂度）。当你需要更好的东西时使用它们。

Answer 8

可能我们应该考虑＆＃34;责任＆＃34;通过这里的方法实现，而不是通过硬数字。如果我们尝试将方法限制为单一责任，LOC将自动处理。

我们可以遵循的另一个经验法则是限制我们可以在单个屏幕上看到的方法的长度。