可能重复:
有多少参数太多了?
我只是在编写一个接受多个值的函数,这让我开始思考。什么时候函数/方法的参数数量太多?何时(如果)表明设计存在缺陷?您是否设计/重构函数以接收结构、数组、指针等以减少参数数量?您是否重构传入的数据只是为了减少参数的数量?不过,这似乎不太适用于 OOP 设计。只是想看看其他人如何看待这个问题。
编辑:作为参考,我刚刚编写的函数接受了 5 个参数。我使用了我的 AP Econ 老师给我的几个定义。2个以上;小于 7。
可能重复:
有多少参数太多了?
我只是在编写一个接受多个值的函数,这让我开始思考。什么时候函数/方法的参数数量太多?何时(如果)表明设计存在缺陷?您是否设计/重构函数以接收结构、数组、指针等以减少参数数量?您是否重构传入的数据只是为了减少参数的数量?不过,这似乎不太适用于 OOP 设计。只是想看看其他人如何看待这个问题。
编辑:作为参考,我刚刚编写的函数接受了 5 个参数。我使用了我的 AP Econ 老师给我的几个定义。2个以上;小于 7。
我不知道,但当我看到它时我就知道了。
根据 Steve McConnell 在Code Complete中的说法,你应该
将例程的参数数量限制为大约七个
如果你不得不问,那可能太多了。
我一般认为,如果参数与功能相关(例如,坐标或颜色分量),则应将它们封装为一个类以获得良好的度量。
并不是说我自己总是遵循这个;)
Robert C. Martin (Uncle Bob) 在Clean Code: A Handbook of Agile Software Craftsmanship中建议最多 3 个
我现在没有这本书,但他的推理与一、二,在较小程度上,三个参数函数读得很好,并清楚地显示了函数的目的。
这当然与他对遵循单一职责原则的非常简短、命名良好的函数的建议密切相关。
快速回答:当你不得不停下来问这个问题时,你的问题太多了。
我个人喜欢将数字保持在六以下。如果需要更多,则解决方案取决于问题。一种方法是使用“setter”函数将值赋予最终将执行您想要的功能的对象。正如您所提到的,另一种选择是使用结构。无论哪种方式,你都不会真的出错。
好吧,这肯定取决于您的功能正在做什么,至于有多少会被认为是“太多”。话虽如此,当然可以有一个带有许多不同参数的函数,这些参数是关于如何在函数内部处理某些情况的选项,并且对那些具有这些选项的合理默认值的函数进行重载。
随着 Intellisense(或其他 IDE 中的等价物)和工具提示的普及,显示 Visual Studio 中 XML 文档的注释,我真的不认为这个问题有明确的答案。
过多的参数是“代码气味”。
您可以划分为多个方法或使用类来重新组合具有共同点的变量。
为“太多”设置一个数字是非常主观的,并且取决于您的组织和您使用的语言,经验法则是,如果您无法阅读方法的签名并知道它是什么做的比你可能有太多的信息。个人而言,我尽量不超过 5 个参数。
我也听说过 7 这个数字,但不知何故,我觉得它源于一个你可以通过原始值传递的时代。
如今,您可以传递对封装了一些复杂状态(和行为)的对象的引用。使用其中的 7 个肯定太多了。
我个人的目标是避免使用超过 4 个。
它很大程度上取决于参数的类型。如果它们都是整数,那么 2 可能太多了。(我怎么记得哪个顺序?)如果任何参数接受 null,那么这个数字会急剧下降。
真正的答案来自问自己:
这取决于编程语言。在 C 中,看到带有 7 个参数的函数并不罕见。但是,在 C# 中,我很少看到超过 5 个参数,我个人通常使用少于 3 个参数。
// In C
draw_dot(x, y, size, red, green, blue, alpha)
// In C#
Point point(x,y);
Color color(red,green,blue,alpha);
Tool.DrawDot(point, color);
对我来说是5。
除此之外,很难管理(记住名称、顺序等)。另外,如果我走到那一步,我有默认值的版本调用这个版本。
也取决于功能,如果您的功能需要大量的用户干预或变量,我不会超过 7-8 范围。就平均参数数量而言,我认为 5-6 是最佳选择。如果您使用的不止这些,您可能希望将类对象视为参数或其他较小的函数。
它因人而异。就个人而言,当我无法通过阅读代码中的调用来立即理解函数调用在做什么时,是时候重构以减轻我的灰色单元格的压力了。
我会说最多 4 。上面的任何东西,我认为都应该放在一个类中。