为什么 .Net 框架指南建议您不要使用 ref/out 参数？

题

显然，他们很“混乱”。这是认真的原因吗？你还能想到其他的吗？

解决方案

您是否看到有多少开发人员不了解ref / out？

我在他们真正需要的地方使用它们，但不是。它们通常只有在你想要有效地返回两个或多个值时才有用 - 在这种情况下，至少思考是否有办法让方法只做一件事。有时使用ref / out 是最合适的方法 - 各种TryParse方法等。

其他提示

在我看来，它们被认为是代码味道，因为通常有更好的选择：返回一个对象。

如果您注意到，在 .NET 库中它们仅在某些特殊情况下使用，即 尝试解析-类似场景：

ref / out自动意味着可变性，而使用不可变值的函数式编程最近风靡一时。尝试将对Dictionary.TryGetValue的调用插入LINQ查询。 API需要声明变量并破坏API中的任何“流畅性”。

这并不是说这是“原因”，而是一个“理由”的例子。

（另见

有关功能语言如何处理此类API的评论。）

混淆可能是最好的理由。混乱意味着可维护性降低，并且在引入细微错误方面可能性增加。我在与“goto”相似的视图中看到它们。控制流程声明。虽然它本身并不是坏事，但它导致许多人在几十年内无法阅读/理解程序。

远离任何可能使您的代码更加混乱的事情。

话虽如此，这些关键字的存在可能是因为框架开发人员认为需要这样的东西。如果没有合适的解决方法，请使用它们，但是尽可能避免使用它们。

ref / out也不适用于“Func”委托，因此这些样式API与使用委托的一些其他API相比较不可组合/可重用。

只是一个想法，当参数捕获目标方法中的执行状态而不是捕获返回的数据时，我发现ref / out是有用的。当您想要从返回Customer对象的服务获取错误消息时，请考虑一种情况。

Customer GetCustomerById(int id, out string errorMessage);

如果此方法失败，您可能会返回null Customer对象或抛出异常。但是，如果我想知道错误的原因（验证？数据库？），我会用掉参数。这里的errorMessage参数与数据无关，只是用来捕获方法执行的错误。

就个人而言，如果我有一个预期会返回两个或更多基本数据/值的方法，我会重新考虑我的代码的设计。

我被告知的原因是当使用ref / out时1.0 GC有问题。 2.0中的GC（也可能不是1.1）没有这些问题所以我通常认为它是一个现在没有用的遗产。

@TraumaPony 如果您向我们提供此.NET框架指南的源（URL或其他内容），那就没问题了。

你应该返回对象可能是他们建议不使用ref或out的最可能原因。

＆QUOT; REF＆QUOT;实际上只需要在传递标量值时使用，但我看到人们常常将它用于通过引用传递的对象。

代码复杂性原因不够吗？比较：

int myValue;
ReadFromSomewhere(ref myValue);

要：

int myValue = ReadFromSomewhere();

许可以下： CC-BY-SA 和归因