例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
这很大程度上取决于你工作的环境。以javascript为例。在javascript中，传递参数的最佳方式是使用带有键/值对的对象，这实际上意味着你只有一个参数。在其他系统中，最佳点将是3或4。
归根结底，这一切都取决于个人品味。
其他回答
根据Perl最佳实践，3个是可以的，4个太多了。这只是一个指导方针，但在我们店里，这是我们努力遵守的。
如果您开始在心里计算签名中的参数，并将它们与调用匹配，那么是时候重构了!
什么时候被认为如此淫秽的东西可以被监管，尽管第一修正案保证了言论自由?根据波特·斯图尔特法官的说法，“当我看到它的时候，我就知道了。”这里也是一样。
我讨厌制定这样的硬性规则，因为答案不仅取决于项目的大小和范围，而且我认为它甚至会改变到模块级别。这取决于你的方法在做什么，或者这个类应该表示什么，2个参数很可能太多了，这是过度耦合的症状。
我建议通过在第一时间提出这个问题，并尽可能多地限定你的问题，你真的知道所有这些。这里最好的解决方案不是依赖于一个硬性的数字，而是在同行中查看设计评审和代码评审，以确定低内聚性和紧密耦合的领域。
不要害怕向同事展示你的工作成果。如果您害怕，这可能是您的代码有问题的更大迹象，并且您已经知道了它。
根据Steve McConnell在Code Complete中的说法，你应该这样做
限制一个程序的数量 参数约为7
我的经验法则是，我需要能够长时间地记住参数，以便查看调用并判断它做了什么。如果我不能看这个方法然后翻到一个方法的调用记住哪个参数是做什么的那就太多了。
对我来说，大约等于5，但我没有那么聪明。你的里程可能会有所不同。
您可以创建一个带有属性的对象来保存参数，并在超出设置的任何限制时将其传入。参见Martin Fowler的《重构》一书和简化方法调用的章节。
