例程可以有参数,这不是新闻。您可以根据需要定义任意多的参数,但是过多的参数会使您的例程难以理解和维护。

当然,您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上,使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:

谨慎的程序员避免将数据捆绑在一起,除非逻辑上是必要的。

因此,如果你的例程有太多的参数,或者你使用一个结构体来掩盖一个大的参数列表,你可能做错了什么。也就是说,你没有保持耦合松散。

我的问题是,什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?


当前回答

对于我来说,当列表在我的IDE上超过一行时,那么它就是一个参数太多了。我想在一行中看到所有的参数,而不中断眼神交流。但这只是我个人的偏好。

其他回答

我要从性能的角度指出的一件事是,根据您向方法传递参数的方式,按值传递大量参数会使程序变慢,因为每个参数都必须被复制,然后放置在堆栈上。

使用单个类来包含所有参数会更好,因为通过引用传递的单个参数将更优雅、更干净、更快!

根据亚马逊创始人杰夫·贝佐斯的说法,最多只能吃两个披萨:

在《干净代码》一书中,罗伯特·c·马丁用了四页纸来讨论这个问题。要点如下:

a的理想参数数 函数为零(niladic)。接下来 一个(单体),紧随其后的是两个 (二元)。三个参数(三元) 应该尽量避免。更多的 Than three (polyadic)要求very 特殊理由——然后 反正也不应该用。

作为一般的经验法则,我停留在三个参数上。如果再多,就应该传递一个参数数组或配置对象,这也允许在不更改API的情况下添加未来的参数。

众所周知,人们平均一次能记住7 +/- 2件事。我喜欢把这个原则用在参数上。假设程序员都是智商高于平均水平的人,我会说任何10+都太多了。

顺便说一句,如果参数在任何方面相似,我会把它们放在向量或列表中,而不是结构体或类中。