函数/过程/方法应该有多less行代码？
可能重复：
什么时候function太长？
我最近被赋予了一个不值得羡慕的任务，那就是审查另一个开发人员编写的糟糕的代码，并logging不好的做法。 （这当然是为了退出开发者的工作而不是为了任何利他的理由！）
审查的代码有几个程序是很多代码行 – 最长的是近600行。 我想到的一些问题是可维护性和可读性。
诀窍是，我需要向一个非专业人士辩解，为什么这是一个不好的做法，如果可能的话，还要备份一本备受好评的现行参考书。 类比也不错。
有任何想法吗？
重复： 什么时候function太长？
重复： 最大规则function的最佳规则？
这不是关于代码行的。 正如史蒂夫·麦克康纳 （ Steve Mcconnell）和鲍勃·马丁 （ Bob Martin）所说（关于编码最佳实践的两个很好的参考），一种方法应该只做一件事， 然而，许多代码需要做的一件事是它应该有多less行。 如果这个“一件事”可以分解成更小的东西，那么每个人都应该有一个方法。
很好的线索你的方法做了不止一件事情：
- 一个方法中有多个级别的缩进（表明太多逻辑分支只做一件事）
- “段落突破” – 逻辑代码组之间的空白表示该方法正在做的不止一件事情
仅举几个。 鲍勃·马丁也说要保持在10左右。就我个人而言，我通常会尝试10次。如果开始接近20，这是一个精神的标志，密切关注该方法。 但最终，LoC几乎是一个不好的指标。 这只是一个有用的指标，可能会指出真正的问题。
真正的答案
没有具体的数字。
一个具体的答案
如果您必须向律师certificate某个数字是合法的，请找出适合您店铺典型开发编辑窗口的最大行数，然后使用它。
一般实践
你甚至不应该这样看，但是在任何一个函数中都不应该有任何复杂的事情发生。
每个单位的工作都应该委托给自己的单位可testing的描述性的方法。 做到这一点，所有的方法最终都是小而可读的，没有数线……
我看到的最大的罪犯是在if语句中爆炸的3-4 +布尔条件。 用一个好名字把所有的东西都包装起来，然后包装起来，这些东西是自己复杂的。
首先，请注意，长度限制与通常的度量完全分开，即“函数只做一件事，做得好吗？ 如果这个问题的答案不是肯定的话，无论如何，这个函数可能不是一个好的函数。
“Code Complete”中的引用特别与最大长度有关，通常被认为是关于编码实践的最佳书籍之一：
有时候，一个复杂的algorithm会导致更长的程序，在这种情况下，程序应该被允许有机增长到100-200行。 （一行是一个非注释，非空白的源代码行。）数十年的证据表明，这样的长度的例程不比更短的例程容易出错。 让诸如嵌套深度，variables数量和其他与复杂性有关的考虑事项决定了程序的长度，而不是强加长度限制本身。
如果您想编写比200行更长的程序，请小心。 没有一项研究报告成本降低，错误率降低，或者两者都有大于200行的大小不同的程序，当你传递200行代码时，你肯定会遇到一个上限的可理解性。
我读了这么多年，但是我认为在Perl学习中 ，他们build议不要再做一个程序，而是一次性把所有东西都放在屏幕上。 我认为这是一个很好的标准。 我已经看到由于重复的代码（例如数据库访问和赋值属性值）而仍然可读的更长的函数，但这些是例外而不是常规。
要增加雷克斯的观点，它也应该尽可能短。 鲍勃·马丁说10或更less
对象导师 – function应该有多大？
尽可能less。
我不记得在哪里，但我想我在.Net中读过编译器优化的简短方法。 我认为他们在30线这样的东西上效果最好。
