例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
我的经验法则是，我需要能够长时间地记住参数，以便查看调用并判断它做了什么。如果我不能看这个方法然后翻到一个方法的调用记住哪个参数是做什么的那就太多了。
对我来说，大约等于5，但我没有那么聪明。你的里程可能会有所不同。
您可以创建一个带有属性的对象来保存参数，并在超出设置的任何限制时将其传入。参见Martin Fowler的《重构》一书和简化方法调用的章节。
其他回答
众所周知，人们平均一次能记住7 +/- 2件事。我喜欢把这个原则用在参数上。假设程序员都是智商高于平均水平的人，我会说任何10+都太多了。
顺便说一句，如果参数在任何方面相似，我会把它们放在向量或列表中，而不是结构体或类中。
在最差的5个代码片段中，检查第二个，“这是一个构造函数吗”。它有37⋅4≈150个参数:
下面是一个程序员写的构造函数[…]你们中的一些人可能认为是的，它是一个很大的构造器，但他使用eclipse自动代码生成工具。NOO，在这个构造函数中，我发现了一个小错误，这让我得出结论，这个构造函数是手工编写的。(顺便说一下，这只是构造函数的顶部部分，它不是完整的)。
I agree with Robert Martin's quote in Clean Code (as cited above): the fewer parameters the better. More than 5-7 parameters and method calls become pretty hard to comprehend. Things get especially bad if some of the parameters are optional (and so take null values), or if all the parameters have the same type (making it even harder to figure out which parameter is which). If you can bundle parameters into cohesive domain objects like Customer and Account, your code will be much more pleasant to work with.
有一个极端的情况:如果你有一个方法调用，它接受一个可变数量的参数，这些参数形成一个逻辑集，有更多的参数会有更少的认知开销。例如，您可能需要一个方法，以重试之间的毫秒数来指定HTTP请求重试次数。可以指定以1s、2s和3s为间隔的三次重试:
retries(1000, 2000, 3000)
在这种有限的情况下，向调用中添加更多参数并不会增加太多的精神负荷。
另一个需要考虑的问题是，您的语言是否支持命名参数列表并允许省略可选参数。较大的已命名参数列表比较大的未命名参数列表更容易理解。
但我还是宁可选择更少的参数，而不是更多的参数。
这个答案假设使用面向对象语言。如果你不使用，跳过这个答案(换句话说，这不是一个语言不可知的答案。
如果你传递了超过3个左右的参数(特别是内在类型/对象)，这并不是“太多”，而是你可能错过了创建一个新对象的机会。
寻找传递给多个方法的参数组——即使是传递给两个方法的参数组也几乎可以保证在那里有一个新对象。
然后，您将功能重构到新对象中，您无法相信它对代码和对OO编程的理解有多大帮助。
短期记忆中的七件事?
函数名称 返回函数的值 函数的目的 参数1 参数2 参数3 参数4
