例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
我的经验法则是，我需要能够长时间地记住参数，以便查看调用并判断它做了什么。如果我不能看这个方法然后翻到一个方法的调用记住哪个参数是做什么的那就太多了。
对我来说，大约等于5，但我没有那么聪明。你的里程可能会有所不同。
您可以创建一个带有属性的对象来保存参数，并在超出设置的任何限制时将其传入。参见Martin Fowler的《重构》一书和简化方法调用的章节。
其他回答
如果我在一个例程中有7-10个参数，我会考虑将它们捆绑到一个新类中，但如果这个类只是一堆带有getter和setter的字段，那么这个新类必须做一些其他的事情，而不是将值移进和移出。否则，我宁愿忍受很长的参数列表。
在最差的5个代码片段中，检查第二个，“这是一个构造函数吗”。它有37⋅4≈150个参数:
下面是一个程序员写的构造函数[…]你们中的一些人可能认为是的，它是一个很大的构造器，但他使用eclipse自动代码生成工具。NOO，在这个构造函数中，我发现了一个小错误，这让我得出结论，这个构造函数是手工编写的。(顺便说一下，这只是构造函数的顶部部分，它不是完整的)。
在我看来，使用长参数列表的理由是数据或上下文本质上是动态的，想想printf();一个使用可变参数的好例子。处理这种情况的一个更好的方法是通过传递一个流或xml结构，这再次减少了参数的数量。
一台机器当然不会介意大量的参数，但是开发人员也会考虑维护开销、单元测试用例和验证检查的数量。设计师也讨厌冗长的参数列表，更多的参数意味着对接口定义的更多更改，无论何时要进行更改。关于耦合/内聚的问题来自以上几个方面。
如果您开始在心里计算签名中的参数，并将它们与调用匹配，那么是时候重构了!
根据Steve McConnell在Code Complete中的说法，你应该这样做
限制一个程序的数量 参数约为7
