函数长度应该有多大(函数中的代码行)?[复制品]

这种问题在 Code Complete . 史蒂夫·麦康奈尔写道 整页 回答这个问题。他的结论是:

几十年的证据表明 这样的长度(>100行)不是 比短的容易出错 日常工作。 让问题如 程序的内聚性、决策的数量 要点,需要的评论数 解释程序,以及其他 与复杂性相关的考虑因素 规定程序的长度 而不是强加长度 限制本身。 也就是说,如果你 希望写入的例程长度超过 大约200行,小心点。

线条是不相关的,但复杂性是。

一个函数应该完成一个任务,并且它应该很容易被发现。你不应该花太多的时间来理解这个函数是如何工作的,以及它是如何工作的。

它应该有它所需要的数量。

我看不出将函数行数限制为屏幕大小有什么意义(公平地说,直到屏幕可以容纳10-20行之后,我才开始编程——也许在某些环境中这是有意义的)。只需根据需要编写函数即可。当它变得如此之大以至于代码片段开始重复时,将这些片段重构为其他函数/类/组件。

这是一个相当武断的经验法则。有的喜欢20行,有的喜欢无卷轴规则。最后,只要确保它可读并且一眼就能容易理解。翻阅你的书 SOLID principles 并确保该方法只有一个职责等。

尽可能长,尽可能短。

我把5-10行作为经验法则,但是如果有一些逻辑不容易(重新)分解成多个函数,我会在必要的地方写更长的时间。另一方面,我的函数通常只有一两行长。

如果你不 不洁地 理解代码的一部分功能,为它编写一个新的函数。

我认为它有多少条线并不重要……只要它是有效的。

任何可以在代码库中的任何地方重用的代码都应该移动到同一类或共享类中的另一个函数/方法并调用。

我以前也听说过屏幕尺寸的度量,但显然不是为了硬性限制,也不是为了与显示器尺寸成比例。它的目的只是传达一个干燥的原则,尽可能保持函数的小是编写代码的最佳方法之一,可以扩展(以项目大小为单位)。

Linux内核编码风格文档说:

功能应该短而甜, 只做一件事。他们应该 适合一到两屏文本 (ISO/ANSI屏幕尺寸为80x24,AS 我们都知道),做一件事然后做 那很好。

现在,我意识到这是在内核代码的上下文中进行的,但是我认为它所做的一些要点是:函数长度通常是有效的。查找副本 here . 功能部分见第4章。

总而言之,函数长度不应该受到某些人为规则的限制;如果它有意义的话,就把它考虑进去,因为它使内容更容易阅读,但是关于1-2个屏幕的规则并不是用石头写的。

从OO的角度来看,这只是一个观点:

我喜欢将我的方法保存在逻辑工作单元中,而不真正关心像loc这样的度量。这也使得正确命名方法变得非常容易,并防止它们变得膨胀。

一个非常简单的函数例子是,我不需要在一个循环中有一个内嵌计算斐波那契序列的函数,而是添加一个后继函数(int a,int b),该函数由斐波那契()函数调用。

OO方式中更复杂的例子是执行GET请求的HTTP客户机。我会把它分解成这样的东西:

Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)

函数应该非常小,足以完成它们的工作,但不能小。