例程可以有参数，这不是新闻。您可以根据需要定义任意多的参数，但是过多的参数会使您的例程难以理解和维护。
当然，您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上，使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起，除非逻辑上是必要的。
因此，如果你的例程有太多的参数，或者你使用一个结构体来掩盖一个大的参数列表，你可能做错了什么。也就是说，你没有保持耦合松散。
我的问题是，什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
当前回答
我基本上同意5，但是，如果在我需要更多的情况下，这是解决问题的最清晰的方法，那么我会使用更多。
其他回答
我同意3个是可以的，4个太多了。如果有3个以上的参数，你就不可避免地要做不止一个任务。一个以上的任务应该被分割成不同的方法。
然而，如果我查看我所从事的最新项目，例外情况比比皆是，大多数情况下很难归结为3个参数。
我基本上同意5，但是，如果在我需要更多的情况下，这是解决问题的最清晰的方法，那么我会使用更多。
您应该考虑的一个相关问题是例程的内聚性如何。大量参数可能是一种气味，告诉您例程本身试图做太多事情，因此它的内聚性是可疑的。我同意一个固定的参数数量可能是不可能的，但我猜一个高内聚例程意味着一个低数量的参数。
I agree with Robert Martin's quote in Clean Code (as cited above): the fewer parameters the better. More than 5-7 parameters and method calls become pretty hard to comprehend. Things get especially bad if some of the parameters are optional (and so take null values), or if all the parameters have the same type (making it even harder to figure out which parameter is which). If you can bundle parameters into cohesive domain objects like Customer and Account, your code will be much more pleasant to work with.
有一个极端的情况:如果你有一个方法调用，它接受一个可变数量的参数，这些参数形成一个逻辑集，有更多的参数会有更少的认知开销。例如，您可能需要一个方法，以重试之间的毫秒数来指定HTTP请求重试次数。可以指定以1s、2s和3s为间隔的三次重试:
retries(1000, 2000, 3000)
在这种有限的情况下，向调用中添加更多参数并不会增加太多的精神负荷。
另一个需要考虑的问题是，您的语言是否支持命名参数列表并允许省略可选参数。较大的已命名参数列表比较大的未命名参数列表更容易理解。
但我还是宁可选择更少的参数，而不是更多的参数。
多了一个。我并不是说要油嘴滑舌，但是有些函数确实需要一些选项。例如:
void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);
有6个论点，每一个都是必不可少的。此外，它们之间没有共同的联系来证明捆绑销售是合理的。也许你可以定义“struct mapargs”，但那更糟糕。
