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

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

谨慎的程序员避免将数据捆绑在一起,除非逻辑上是必要的。

因此,如果你的例程有太多的参数,或者你使用一个结构体来掩盖一个大的参数列表,你可能做错了什么。也就是说,你没有保持耦合松散。

我的问题是,什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?


当前回答

只有在某些参数是冗余的情况下,函数才可能有过多的参数。如果使用了所有参数,则函数必须具有正确的参数数量。以这个常用的函数为例:

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个),还有从类名派生的参数。你将如何减少这种情况?你想把数字减少到更精确的程度吗?

不要让参数的数量困扰你,只要确保它是合乎逻辑的,并有良好的文档记录,让智能感知*帮助你。

*其他编码助手可用!

其他回答

您应该考虑的一个相关问题是例程的内聚性如何。大量参数可能是一种气味,告诉您例程本身试图做太多事情,因此它的内聚性是可疑的。我同意一个固定的参数数量可能是不可能的,但我猜一个高内聚例程意味着一个低数量的参数。

我自己把公共函数的极限画在5个参数上。

恕我直言,长参数列表只适用于私有/本地helper函数,这些函数只能从代码中的几个特定位置调用。在这些情况下,您可能需要传递大量的状态信息,但可读性并不是一个大问题,因为只有您(或维护您的代码并应该了解模块基础的人)必须关心调用该函数。

如果您开始在心里计算签名中的参数,并将它们与调用匹配,那么是时候重构了!

根据Perl最佳实践,3个是可以的,4个太多了。这只是一个指导方针,但在我们店里,这是我们努力遵守的。

什么时候被认为如此淫秽的东西可以被监管,尽管第一修正案保证了言论自由?根据波特·斯图尔特法官的说法,“当我看到它的时候,我就知道了。”这里也是一样。

我讨厌制定这样的硬性规则,因为答案不仅取决于项目的大小和范围,而且我认为它甚至会改变到模块级别。这取决于你的方法在做什么,或者这个类应该表示什么,2个参数很可能太多了,这是过度耦合的症状。

我建议通过在第一时间提出这个问题,并尽可能多地限定你的问题,你真的知道所有这些。这里最好的解决方案不是依赖于一个硬性的数字,而是在同行中查看设计评审和代码评审,以确定低内聚性和紧密耦合的领域。

不要害怕向同事展示你的工作成果。如果您害怕,这可能是您的代码有问题的更大迹象,并且您已经知道了它。