例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
您应该考虑的一个相关问题是例程的内聚性如何。大量参数可能是一种气味，告诉您例程本身试图做太多事情，因此它的内聚性是可疑的。我同意一个固定的参数数量可能是不可能的，但我猜一个高内聚例程意味着一个低数量的参数。
其他回答
多了一个。我并不是说要油嘴滑舌，但是有些函数确实需要一些选项。例如:
void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);
有6个论点，每一个都是必不可少的。此外，它们之间没有共同的联系来证明捆绑销售是合理的。也许你可以定义“struct mapargs”，但那更糟糕。
我的答案将基于函数被调用的频率。
如果它是一个只被调用一次的init函数，那么就让它占用10个parms或更多，谁在乎呢。
如果它每帧被调用一堆次，那么我倾向于创建一个结构，并只传递一个指针给它，因为这往往更快(假设你不是每次都重建结构)。
我想说，只要你有2-4的过载，如果你需要的话，你就可以去更高的地方。
我要从性能的角度指出的一件事是，根据您向方法传递参数的方式，按值传递大量参数会使程序变慢，因为每个参数都必须被复制，然后放置在堆栈上。
使用单个类来包含所有参数会更好，因为通过引用传递的单个参数将更优雅、更干净、更快!
我自己把公共函数的极限画在5个参数上。
恕我直言，长参数列表只适用于私有/本地helper函数，这些函数只能从代码中的几个特定位置调用。在这些情况下，您可能需要传递大量的状态信息，但可读性并不是一个大问题，因为只有您(或维护您的代码并应该了解模块基础的人)必须关心调用该函数。
