对于我来说，当列表在我的IDE上超过一行时，那么它就是一个参数太多了。我想在一行中看到所有的参数，而不中断眼神交流。但这只是我个人的偏好。

非常感谢你的所有回答:

It was a bit surprising to find people who also think (like I do) that 5 parameters is a good limit for the sanity of the code. Generally, people tend to agree that a limit between 3 and 4 is good rule of thumb. This is reasonable as people usually have a bad time counting more than 4 things. As Milan points, on average people can keep more or less 7 things in their head at a time. But I think that you can't forget that, when you are designing/maintaining/studying a routine, you have to keep in mind more things than just the parameters. Some people consider that a routine should have as many arguments as it needs to. I agree, but only for a few specific cases (calls to OS APIs, routines where optimization is important, etc). I suggest to hide the complexity of these routines by adding a layer of abstraction just above these calls whenever possible. Nick has some interesting thoughts on this. If you don't want to read his comments, I summarize for you: in a nutshell, it depends: I hate making hard and fast rules like this because the answer changes not only depending on the size and scope of your project, but I think it changes even down to the module level. Depending on what your method is doing, or what the class is supposed to represent, it's quite possible that 2 arguments is too many and is a symptom of too much coupling. The moral here is don't be afraid of showing your code to your peers, discuss with them and try to "identify areas where you have low cohesion and tight coupling". Finally, I think wnoise much agrees with Nick, and concludes his satirical contribution with this poetical vision (see comments below) of the art of programming: Programming is not engineering. Organization of code is an art because it depends on human factors, which depend too much on context for any hard rule.

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

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

97听起来差不多。

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

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.

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)

在这种有限的情况下，向调用中添加更多参数并不会增加太多的精神负荷。

另一个需要考虑的问题是，您的语言是否支持命名参数列表并允许省略可选参数。较大的已命名参数列表比较大的未命名参数列表更容易理解。

但我还是宁可选择更少的参数，而不是更多的参数。