例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
在《干净代码》一书中，罗伯特·c·马丁用了四页纸来讨论这个问题。要点如下:
a的理想参数数 函数为零(niladic)。接下来 一个(单体)，紧随其后的是两个 (二元)。三个参数(三元) 应该尽量避免。更多的 Than three (polyadic)要求very 特殊理由——然后 反正也不应该用。
其他回答
Alan Perlis著名的编程警句之一(在ACM SIGPLAN notice 17(9)， 1982年9月中重新叙述)指出:“如果您有一个带有10个参数的过程，那么您可能错过了一些参数。”
在最差的5个代码片段中，检查第二个，“这是一个构造函数吗”。它有37⋅4≈150个参数:
下面是一个程序员写的构造函数[…]你们中的一些人可能认为是的，它是一个很大的构造器，但他使用eclipse自动代码生成工具。NOO，在这个构造函数中，我发现了一个小错误，这让我得出结论，这个构造函数是手工编写的。(顺便说一下，这只是构造函数的顶部部分，它不是完整的)。
对于我来说，当列表在我的IDE上超过一行时，那么它就是一个参数太多了。我想在一行中看到所有的参数，而不中断眼神交流。但这只是我个人的偏好。
A length restriction on a parameter list is just one more restriction. And restriction means applied violence. It sounds funny, but you can be non-violent even when programming. Just let the code dictate the rules. It is obvious that if you have many parameters, the body of the function/class method will be big enough to make use of them. And big code snippets usually can be refactored and split into smaller chunks. So you get solution against having many parameters as free bonus, since they are split among the smaller refactored pieces of code.
97听起来差不多。
少了一点，你就失去了灵活性。
