多少个参数太多？

Question

例程可以有参数，这不是新闻。您可以根据需要定义任意数量的参数，但是参数太多会使您的例程难以理解和维护。

当然，您可以使用结构化变量作为解决方法：将所有这些变量放在单个结构中，然后将其传递给例程。实际上，使用结构简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说：

谨慎的程序员避免捆绑数据超出逻辑上的必要性。

因此，如果您的例程中有太多参数，或者您使用结构来掩盖大参数列表，则可能是您做错了什么。也就是说，您不会使耦合松动。

我的问题是，何时可以考虑参数列表太大？我认为超过5个参数太多了。你怎么看？

Answer 1

如果某些参数是冗余的，则函数只能具有太多参数。如果使用了所有参数，则该函数必须具有正确数量的参数。采取以下常用功能：HWND CreateWindowEx(  DWORD dwExStyle,  LPCTSTR lpClassName,  LPCTSTR lpWindowName,  DWORD dwStyle,  int x,  int y,  int nWidth,  int nHeight,  HWND hWndParent,  HMENU hMenu,  HINSTANCE hInstance,  LPVOID lpParam);这是12个参数（如果将x，y，w和h捆绑为矩形，则为9），并且还有从类名派生的参数。您将如何减少呢？您是否想进一步减少数量？不要让参数的数量困扰您，只需确保它是合乎逻辑的并有据可查，并让intellisense *可以为您提供帮助。

Answer 2

非常感谢您的所有回答：令人惊讶的是，找到像我一样也认为5个参数是代码健全性的一个很好的限制的人。通常，人们倾向于认为3到4之间的限制是很好的经验法则。这是合理的，因为人们通常很难计算4件以上的事情。正如米兰所指出的，平均每个人一次最多可以保留7件事。但是我认为您不能忘记，在设计/维护/研究例程时，您不仅要记住参数，还必须记住更多的事情。有人认为例程应包含所需的尽可能多的参数。我同意，但仅适用于一些特定情况（对OS API的调用，对优化很重要的例程等）。我建议通过在可能的时候在这些调用之上添加一个抽象层来隐藏这些例程的复杂性。尼克对此有一些有趣的想法。如果您不想阅读他的评论，那么我为您总结：简而言之，这取决于：我讨厌制定如此严格的规则，因为答案不仅会根据项目的大小和范围而变化，而且我认为它甚至会在模块级别变化。根据您的方法正在执行的操作或类应表示的内容，两个参数很可能太多，并且是过多耦合的征兆。这里的道义是不要害怕向同行展示您的代码，与他们讨论并尝试“识别出内聚力低和耦合紧密的区域”。最后，我认为无奈与尼克非常吻合，并以这种对编程艺术的诗意见解（见下面的评论）总结了他的讽刺贡献：编程不是工程。代码的组织是一门艺术，因为它取决于人为因素，对于任何硬性规则，人为因素都过于依赖于上下文。