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

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

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

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

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


当前回答

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

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

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

其他回答

这很大程度上取决于你工作的环境。以javascript为例。在javascript中,传递参数的最佳方式是使用带有键/值对的对象,这实际上意味着你只有一个参数。在其他系统中,最佳点将是3或4。

归根结底,这一切都取决于个人品味。

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

我过去使用的一些代码使用全局变量,只是为了避免传递太多参数。

请不要这样做!

(通常)。

97听起来差不多。

少了一点,你就失去了灵活性。

在我看来,使用长参数列表的理由是数据或上下文本质上是动态的,想想printf();一个使用可变参数的好例子。处理这种情况的一个更好的方法是通过传递一个流或xml结构,这再次减少了参数的数量。

一台机器当然不会介意大量的参数,但是开发人员也会考虑维护开销、单元测试用例和验证检查的数量。设计师也讨厌冗长的参数列表,更多的参数意味着对接口定义的更多更改,无论何时要进行更改。关于耦合/内聚的问题来自以上几个方面。