C＃方法中有多少参数可以接受？

我是C＃的新手，必须维护一个C＃应用程序。现在我发现了一个具有32个参数（不是自动生成的代码）的方法。

从C / C ++我记得经验法则“4参数”。它可能是一个老式的规则，它回溯到旧的0x86编译器，其中4个参数可以容纳在寄存器中（快速）或者在堆栈中。

我并不关心性能，但我确实感觉即使在C＃中，每个function的32个参数也不容易维护。

或者我完全不是最新的？

C＃的经验法则是什么？

谢谢你的提示！

没有普遍的共识，这取决于你问的是谁。

一般来说 – 当下可读性受到影响，有太多……

鲍勃马丁说理想的参数数量是0，而3正在拉伸它。

32个参数是一个巨大的代码气味。这意味着class级有太多的责任，需要重构。甚至应用参数对象重构听起来像是隐藏了一个糟糕的设计而不是解决问题。

从第10周的清洁代码提示：

函数应该有少量参数。没有争论是最好的，其次是一，二，三。超过三个是非常值得怀疑的，应该避免偏见。

嗯32参数太多了。我猜的人数和人数一样多。但是，常识要求超过6个变得笨拙。

如果您有这么多参数，最好将对象作为单个参数传递并将参数作为属性，至少更容易阅读。

我相信开发人员社区的共同感觉是最多5或6个参数。我见过像你这样的方法的时代，有人做了类似“SaveCustomer”的事情并传递了每个字段而不是传递客户对象。

C＃没有最大允许参数数量，AFAIK。
但IL确实：0x1FFFFFFF。

当然，这篇文章并不是编写具有大量参数的方法的指南。

对此没有灵丹妙药的答案。一切都取决于你和你的开发团队。参数的数量也可能会出现在32这样的数字上，即使这会导致人们考虑设计不佳，但这种情况可能会在职业生涯中遇到。

对此的一般协议是

一般来说，他们说code-line不会太长，然后限制你在编辑器中水平滚动，即使这与问题主题没有严格关联，但可能会引发一些想法。

希望这可以帮助。

你可以通过创建一个作为单个参数传入的对象来采取另一种方法吗？

我从未对参数有过经验法则，但常识和实用性通常占主导地位。

虽然我怀疑这个问题会被关闭作为争议，但32肯定是太多了。

一种选择是查看构建器模式，这将至少使任务更具可读性。

我认为现在最重要的是人类的可读性而不是表现。我怀疑.NET中是否存在类似的性能行为，但即使它确实如此，正确的代码比执行速度稍快但执行错误的代码更有用。通过使其易于理解，您可以增加代码正确的机会。

一些参数 – 在我的经验中很少超过5 – 在大多数情况下是最好的。您可以考虑通过在随后调用该方法的类上以属性的forms提供参数来重构需要更多代码的代码。

我认为每种方法最多有五个参数是令人愉快的。但这取决于不同的东西，如编码风格和类设计。

查看.NET Framework，您将经常看到：

保持您的公共API尽可能简单。较少的参数可以帮助其他开发人员使用您的课程，而无需了解“它如何工作”。使代码更清晰。

瓦伦丁你有正确的感觉，32个参数只意味着一个 – 完全错误的东西。根据我过去的C ++经验，我只看到一个“参数”领导者：
这是Win32 APi CreateWindow有11个参数。
你永远不应该使用如此大量的参数。

另一方面，如果您对理论问题感兴趣（可能会在面试中询问） – 方法允许的参数数量是多少？
所以，这里提到上面的C＃方法可以有不超过0x1FFFFFFF的参数（IL限制）。
你可以使用params []数组来设置如此庞大的数量。

为什么这样的限制呢？
因为，如果您将此值转换为字节，并按引用大小（4个字节）将其转换为多个，则您将收到2 GB。
.NET中的所有对象都有2 GB的限制，绝不允许您创建超过2 GB的单个对象。

据我所知，你应该有多少参数没有硬性规定。这完全取决于你在做什么。

但是对于大多数应用来说，32个参数听起来有点太多了。这可能表明设计不好。如果仔细观察，可能有办法简化事情。