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