例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
对于我来说，当列表在我的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.
我认为实际的数字取决于函数上下文的逻辑意义。我同意大约4-5个参数开始变得拥挤。
在设置标志的情况下，处理这种情况的一个好方法是枚举值并将它们一起OR。
根据Perl最佳实践，3个是可以的，4个太多了。这只是一个指导方针，但在我们店里，这是我们努力遵守的。
根据我的说法，可能会有超过4个或某个固定数字的情况。 需要注意的事情可能是
你的方法做的太多了，你需要重构。 您可能需要考虑使用集合或某些数据结构。 重新考虑你的类设计，也许有些东西不需要传递。
从易于使用或易于阅读代码的角度来看，我认为当您需要对方法签名进行“换行”时，应该停下来思考，除非您感到无助，所有使签名更小的努力都没有结果。在过去和现在，一些非常好的图书馆使用超过4-5辆婴儿车。
