例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
根据我的说法，可能会有超过4个或某个固定数字的情况。 需要注意的事情可能是
你的方法做的太多了，你需要重构。 您可能需要考虑使用集合或某些数据结构。 重新考虑你的类设计，也许有些东西不需要传递。
从易于使用或易于阅读代码的角度来看，我认为当您需要对方法签名进行“换行”时，应该停下来思考，除非您感到无助，所有使签名更小的努力都没有结果。在过去和现在，一些非常好的图书馆使用超过4-5辆婴儿车。
其他回答
众所周知，人们平均一次能记住7 +/- 2件事。我喜欢把这个原则用在参数上。假设程序员都是智商高于平均水平的人，我会说任何10+都太多了。
顺便说一句，如果参数在任何方面相似，我会把它们放在向量或列表中，而不是结构体或类中。
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.
多了一个。我并不是说要油嘴滑舌，但是有些函数确实需要一些选项。例如:
void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);
有6个论点，每一个都是必不可少的。此外，它们之间没有共同的联系来证明捆绑销售是合理的。也许你可以定义“struct mapargs”，但那更糟糕。
短期记忆中的七件事?
函数名称 返回函数的值 函数的目的 参数1 参数2 参数3 参数4
我认为实际的数字取决于函数上下文的逻辑意义。我同意大约4-5个参数开始变得拥挤。
在设置标志的情况下，处理这种情况的一个好方法是枚举值并将它们一起OR。
