例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
我要从性能的角度指出的一件事是，根据您向方法传递参数的方式，按值传递大量参数会使程序变慢，因为每个参数都必须被复制，然后放置在堆栈上。
使用单个类来包含所有参数会更好，因为通过引用传递的单个参数将更优雅、更干净、更快!
其他回答
对于我来说，当列表在我的IDE上超过一行时，那么它就是一个参数太多了。我想在一行中看到所有的参数，而不中断眼神交流。但这只是我个人的偏好。
作为一般的经验法则，我停留在三个参数上。如果再多，就应该传递一个参数数组或配置对象，这也允许在不更改API的情况下添加未来的参数。
众所周知，人们平均一次能记住7 +/- 2件事。我喜欢把这个原则用在参数上。假设程序员都是智商高于平均水平的人，我会说任何10+都太多了。
顺便说一句，如果参数在任何方面相似，我会把它们放在向量或列表中，而不是结构体或类中。
这很大程度上取决于你工作的环境。以javascript为例。在javascript中，传递参数的最佳方式是使用带有键/值对的对象，这实际上意味着你只有一个参数。在其他系统中，最佳点将是3或4。
归根结底，这一切都取决于个人品味。
这个答案假设使用面向对象语言。如果你不使用，跳过这个答案(换句话说，这不是一个语言不可知的答案。
如果你传递了超过3个左右的参数(特别是内在类型/对象)，这并不是“太多”，而是你可能错过了创建一个新对象的机会。
寻找传递给多个方法的参数组——即使是传递给两个方法的参数组也几乎可以保证在那里有一个新对象。
然后，您将功能重构到新对象中，您无法相信它对代码和对OO编程的理解有多大帮助。
