C＃，编写更长的方法或更短的方法？

Question

我对此有两种矛盾的看法。 一些消息来源说减少方法调用的方法应该少一些，但是其他一些消息来源说，编写更短的方法对于让JIT进行优化是有好处的。

那么，哪一方是正确的？

Answer 1

实际上进行方法调用的开销在大多数情况下都是无关紧要的。 您永远不必担心它，除非您能够清楚地确定需要重新审视问题的问题（您不会）。

您的代码简单，可读，模块化，可维护和可修改更为重要。 方法应该做一件事，只做一件事，并将子事务委托给其他例程。 这意味着您的方法应该尽可能短，但不能更短。 通过使代码更容易出错并因为它很简单，您可以看到更多的性能优势，而不是试图超越编译器或运行时。

在许多层面上，说方法应该很长的来源是错误的 。

Answer 2

没有，你应该有相对较短的方法来实现可读性 。

Answer 3

关于功能大小没有一个简单的规则。 指南应该是一个功能应该做“一件事”。 这有点模糊，但随着经验变得更容易。 小功能通常会带来可读性。 偶尔需要大的。

担心方法调用的开销是过早的优化。

Answer 4

一如既往，这是关于找到一个良好的平衡。 最重要的是该方法只做一件事 。 更长的方法往往不止一件事。

Answer 5

指导您确定尺寸方法的最佳单一标准是使它们具有良好的可测性 。 如果你可以（实际上是DO！ - ）对每一种方法进行彻底的单元测试，那么你的代码可能会非常好; 如果你吝啬测试，你的代码可能充其量只是平庸。 如果一种方法很难彻底测试，那么这种方法很可能“太大” - 试图做太多事情，因此也难以阅读和维护（以及经过严格测试，因此可能是错误）。

Answer 6

首先，你绝对不应该在方法数量级别上微观优化性能。 您很可能无法获得任何可衡量的性能优势。 只有当你有一些方法在紧密循环中被调用数百万次时，这可能是一个想法 - 但是在你需要它之​​前不要开始优化它。

你应该坚持使用简洁的方法，这样做可以使方法的意图明确。 这将为您提供易于阅读的代码，更易于理解并促进代码重用。

Answer 7

编写代码时要考虑的最重要的成本是可维护性。 你会花很多 很多的时间来维护应用程序和修复bug比你会解决性能问题。

在这种情况下，与维护大型笨重方法的成本相比，调用方法几乎肯定无足轻重的成本非常小。 小巧简洁的方法更易于维护和理解。 此外，调用该方法的成本几乎肯定不会对您的应用程序产生显着的性能影响。 如果确实如此，您只能通过使用分析器确定这一点。 众所周知，开发人员很难在手头识别性能问题。

一般来说，一旦发现性能问题，就很容易解决。 制作方法或更重要的是代码库，可维护是一个更高的成本。

Answer 8

就个人而言，只要编写它们的人写得很好，我就不会害怕冗长的方法（每个子任务由2个换行符分隔，并且在它之前有一个很好的评论，等等。同样，识别非常重要。）。 实际上，很多时候我甚至更喜欢它们（例如，在编写以顺序逻辑按特定顺序执行操作的代码时）。

另外，我真的不明白为什么将长方法分成100块会提高可读性（正如其他人所说）。 只是相反。 你只会最终跳到地方并在你的记忆中保存代码片段，以便全面了解你的代码中发生了什么。 将其与可能缺少注释，错误的函数名称，许多类似的函数名称相结合，您就拥有了完美的混乱配方。 此外，您可以在尝试减小方法的大小时转到另一端：创建许多类和许多函数，每个函数可能需要许多参数。 我认为这不会提高可读性（特别是对于一个不知道每个类/方法做什么的项目的初学者）。

而“一个功能应该做'一件事'”的要求是非常主观的。 “一件事”可能是将一个变量增加一个，相当于为“同一件事”做大量的工作。

我的规则只是可重用性：相同的代码不应该在很多地方多次出现。 如果是这种情况，您需要一个新功能。 所有其余的只是哲学的话题。 在“为什么你的方法如此大”的问题中，我回答说，“如果代码很简单，为什么不呢？”。

（只是我的意见 - 尽可能多地投票）