例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
根据Perl最佳实践，3个是可以的，4个太多了。这只是一个指导方针，但在我们店里，这是我们努力遵守的。
其他回答
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.
似乎除了数字之外还有其他的考虑因素，以下是我想到的一些:
与函数主要目的的逻辑关系vs.一次性设置 如果它们只是环境标志，那么捆绑会非常方便
我要从性能的角度指出的一件事是，根据您向方法传递参数的方式，按值传递大量参数会使程序变慢，因为每个参数都必须被复制，然后放置在堆栈上。
使用单个类来包含所有参数会更好，因为通过引用传递的单个参数将更优雅、更干净、更快!
什么时候被认为如此淫秽的东西可以被监管，尽管第一修正案保证了言论自由?根据波特·斯图尔特法官的说法，“当我看到它的时候，我就知道了。”这里也是一样。
我讨厌制定这样的硬性规则，因为答案不仅取决于项目的大小和范围，而且我认为它甚至会改变到模块级别。这取决于你的方法在做什么，或者这个类应该表示什么，2个参数很可能太多了，这是过度耦合的症状。
我建议通过在第一时间提出这个问题，并尽可能多地限定你的问题，你真的知道所有这些。这里最好的解决方案不是依赖于一个硬性的数字，而是在同行中查看设计评审和代码评审，以确定低内聚性和紧密耦合的领域。
不要害怕向同事展示你的工作成果。如果您害怕，这可能是您的代码有问题的更大迹象，并且您已经知道了它。
如果您开始在心里计算签名中的参数，并将它们与调用匹配，那么是时候重构了!
