例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
什么时候被认为如此淫秽的东西可以被监管，尽管第一修正案保证了言论自由?根据波特·斯图尔特法官的说法，“当我看到它的时候，我就知道了。”这里也是一样。
我讨厌制定这样的硬性规则，因为答案不仅取决于项目的大小和范围，而且我认为它甚至会改变到模块级别。这取决于你的方法在做什么，或者这个类应该表示什么，2个参数很可能太多了，这是过度耦合的症状。
我建议通过在第一时间提出这个问题，并尽可能多地限定你的问题，你真的知道所有这些。这里最好的解决方案不是依赖于一个硬性的数字，而是在同行中查看设计评审和代码评审，以确定低内聚性和紧密耦合的领域。
不要害怕向同事展示你的工作成果。如果您害怕，这可能是您的代码有问题的更大迹象，并且您已经知道了它。
其他回答
对于我来说，当列表在我的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.
如果我在一个例程中有7-10个参数，我会考虑将它们捆绑到一个新类中，但如果这个类只是一堆带有getter和setter的字段，那么这个新类必须做一些其他的事情，而不是将值移进和移出。否则，我宁愿忍受很长的参数列表。
我自己把公共函数的极限画在5个参数上。
恕我直言，长参数列表只适用于私有/本地helper函数，这些函数只能从代码中的几个特定位置调用。在这些情况下，您可能需要传递大量的状态信息，但可读性并不是一个大问题，因为只有您(或维护您的代码并应该了解模块基础的人)必须关心调用该函数。
