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

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

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

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

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


当前回答

我认为实际的数字取决于函数上下文的逻辑意义。我同意大约4-5个参数开始变得拥挤。

在设置标志的情况下,处理这种情况的一个好方法是枚举值并将它们一起OR。

其他回答

我同意3个是可以的,4个太多了。如果有3个以上的参数,你就不可避免地要做不止一个任务。一个以上的任务应该被分割成不同的方法。

然而,如果我查看我所从事的最新项目,例外情况比比皆是,大多数情况下很难归结为3个参数。

多了一个。我并不是说要油嘴滑舌,但是有些函数确实需要一些选项。例如:

void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

有6个论点,每一个都是必不可少的。此外,它们之间没有共同的联系来证明捆绑销售是合理的。也许你可以定义“struct mapargs”,但那更糟糕。

根据Steve McConnell在Code Complete中的说法,你应该这样做

限制一个程序的数量 参数约为7

如果您开始在心里计算签名中的参数,并将它们与调用匹配,那么是时候重构了!

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