例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
似乎除了数字之外还有其他的考虑因素，以下是我想到的一些:
与函数主要目的的逻辑关系vs.一次性设置 如果它们只是环境标志，那么捆绑会非常方便
其他回答
我同意3个是可以的，4个太多了。如果有3个以上的参数，你就不可避免地要做不止一个任务。一个以上的任务应该被分割成不同的方法。
然而，如果我查看我所从事的最新项目，例外情况比比皆是，大多数情况下很难归结为3个参数。
如果您开始在心里计算签名中的参数，并将它们与调用匹配，那么是时候重构了!
似乎除了数字之外还有其他的考虑因素，以下是我想到的一些:
与函数主要目的的逻辑关系vs.一次性设置 如果它们只是环境标志，那么捆绑会非常方便
您应该考虑的一个相关问题是例程的内聚性如何。大量参数可能是一种气味，告诉您例程本身试图做太多事情，因此它的内聚性是可疑的。我同意一个固定的参数数量可能是不可能的，但我猜一个高内聚例程意味着一个低数量的参数。
我想说，只要你有2-4的过载，如果你需要的话，你就可以去更高的地方。
