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

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

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

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

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


当前回答

97听起来差不多。

少了一点,你就失去了灵活性。

其他回答

众所周知,人们平均一次能记住7 +/- 2件事。我喜欢把这个原则用在参数上。假设程序员都是智商高于平均水平的人,我会说任何10+都太多了。

顺便说一句,如果参数在任何方面相似,我会把它们放在向量或列表中,而不是结构体或类中。

在我看来,使用长参数列表的理由是数据或上下文本质上是动态的,想想printf();一个使用可变参数的好例子。处理这种情况的一个更好的方法是通过传递一个流或xml结构,这再次减少了参数的数量。

一台机器当然不会介意大量的参数,但是开发人员也会考虑维护开销、单元测试用例和验证检查的数量。设计师也讨厌冗长的参数列表,更多的参数意味着对接口定义的更多更改,无论何时要进行更改。关于耦合/内聚的问题来自以上几个方面。

Alan Perlis著名的编程警句之一(在ACM SIGPLAN notice 17(9), 1982年9月中重新叙述)指出:“如果您有一个带有10个参数的过程,那么您可能错过了一些参数。”

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

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

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

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

在最差的5个代码片段中,检查第二个,“这是一个构造函数吗”。它有37⋅4≈150个参数:

下面是一个程序员写的构造函数[…]你们中的一些人可能认为是的,它是一个很大的构造器,但他使用eclipse自动代码生成工具。NOO,在这个构造函数中,我发现了一个小错误,这让我得出结论,这个构造函数是手工编写的。(顺便说一下,这只是构造函数的顶部部分,它不是完整的)。