函数/过程/方法应该有多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线这样的东西上效果最好。