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

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

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

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

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


当前回答

在最差的5个代码片段中,检查第二个,“这是一个构造函数吗”。它有37⋅4≈150个参数:

下面是一个程序员写的构造函数[…]你们中的一些人可能认为是的,它是一个很大的构造器,但他使用eclipse自动代码生成工具。NOO,在这个构造函数中,我发现了一个小错误,这让我得出结论,这个构造函数是手工编写的。(顺便说一下,这只是构造函数的顶部部分,它不是完整的)。

其他回答

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

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

97听起来差不多。

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

您应该考虑的一个相关问题是例程的内聚性如何。大量参数可能是一种气味,告诉您例程本身试图做太多事情,因此它的内聚性是可疑的。我同意一个固定的参数数量可能是不可能的,但我猜一个高内聚例程意味着一个低数量的参数。

短期记忆中的七件事?

函数名称 返回函数的值 函数的目的 参数1 参数2 参数3 参数4

我的答案将基于函数被调用的频率。

如果它是一个只被调用一次的init函数,那么就让它占用10个parms或更多,谁在乎呢。

如果它每帧被调用一堆次,那么我倾向于创建一个结构,并只传递一个指针给它,因为这往往更快(假设你不是每次都重建结构)。