例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
我认为实际的数字取决于函数上下文的逻辑意义。我同意大约4-5个参数开始变得拥挤。
在设置标志的情况下，处理这种情况的一个好方法是枚举值并将它们一起OR。
其他回答
如果您开始在心里计算签名中的参数，并将它们与调用匹配，那么是时候重构了!
在最差的5个代码片段中，检查第二个，“这是一个构造函数吗”。它有37⋅4≈150个参数:
下面是一个程序员写的构造函数[…]你们中的一些人可能认为是的，它是一个很大的构造器，但他使用eclipse自动代码生成工具。NOO，在这个构造函数中，我发现了一个小错误，这让我得出结论，这个构造函数是手工编写的。(顺便说一下，这只是构造函数的顶部部分，它不是完整的)。
根据Perl最佳实践，3个是可以的，4个太多了。这只是一个指导方针，但在我们店里，这是我们努力遵守的。
我过去使用的一些代码使用全局变量，只是为了避免传递太多参数。
请不要这样做!
(通常)。
在《干净代码》一书中，罗伯特·c·马丁用了四页纸来讨论这个问题。要点如下:
a的理想参数数 函数为零(niladic)。接下来 一个(单体)，紧随其后的是两个 (二元)。三个参数(三元) 应该尽量避免。更多的 Than three (polyadic)要求very 特殊理由——然后 反正也不应该用。
