代码分析返回建议，不要使用“out”参数。

Question

我使用VS 2008代码分析工具对我创建的一个对象进行了分析，收到了以下建议...

警告147 CA1021: Microsoft.Design：考虑一种设计，不要要求“returnValue”成为out参数。

我发现"out"参数相当有用，并没有意识到它们被认为是一种不受欢迎的设计实践。我想知道为什么会收到这个警告？如果这是不好的实践？为什么？什么才是好的实践？

我感激任何建议。

- user26901

---

@Lasse：很遗憾，我的雇主不允许我发布专有代码示例。请见谅。我可以说大多数方法都具有“bool”返回类型以指示成功/失败，并且我们使用“out”参数返回数据。感谢您的回复！ - user26901

如今，使用返回类型来表示成功和失败已经不是一个好的形式了。 - quillbreaker

Answer 1

每个代码分析警告都有相关的文档，您可以通过突出显示警告并按F1键来访问文档。您也可以右键单击该项以获得帮助。

无论如何，这里是解释该特定警告的文档。

我会说，在一些情况下，输出参数仍然是一个不错的选择，特别是当涉及到TryParse编码习惯用法时，因为它是一个如此成熟的做事方式，大多数人都应该能够理解它。

然而，在一般使用中，有更好的、更面向对象的解决方案来处理多个返回值。

- Mark Seemann

---

@Mark：谢谢你提供的信息和链接！我之前没有意识到F1的细节，这个链接很好地解释了正在发生的事情。感谢你的回复！ - user26901

“TryParse”编程习惯（例如：Int32.TryParse Method）非常有用，因为它允许测试一个值而无需潜在地处理异常。抛出异常在计算上是昂贵的。 - DavidRR

Answer 2

我曾经对我的项目进行了自我代码分析。虽然我得到了很多有见地的建议，但我很快就关闭了它。其中许多建议是宗教性质的，你可以这样做或者那样做，这是一种风格而不是不好的实践。

针对你的情况。如果你只有一个返回参数，那么将其从函数中返回。

如果你还有一个返回码占用了返回位置，考虑使用异常来通知调用者操作错误。

如果你有许多密切相关的参数需要返回，可以创建一个类/结构体将它们组合在一起，并将其作为一个整体返回。

- user151323

---

我认为称加州规则为宗教不公平。其中绝大多数都是基于API设计的深入分析和对大多数开发人员理解情况的案例研究。《框架设计指南》（http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321246756）这本书提供了很多有启发性的见解。也许你不同意这些规则，你当然可以选择不使用它们，但它们绝不是“宗教”。 - Mark Seemann

@Mark，许多CA规则存在的问题在于，详尽的分析是关于公共API的，而当供应商（Microsoft）无法获得客户端代码重新编译时，它应该如何运作。这在大多数普通程序员编写的代码中并非如此。 - Ian Ringrose

Answer 3

许多代码分析警告对编写第三方将使用的API代码似乎很相关，例如“out”参数规则：不使用它们的原因之一是因为许多其他程序员不知道它们的存在。

如果这些警告与您编写的内容不匹配，则可以关闭不适合您的代码分析规则。个人而言，我倾向于关闭命名、可移植性和互操作性规则，因为它们对我编写的代码类型不相关。

- Dr Herbie

Answer 4

在我的大多数项目中，我已经关闭了这个特定的警告。因为我知道，当我使用一个输出参数时，我有充分的理由这样做，因为我尽量避免使用它们。

不过，当你在一个项目中与多个人合作时，如果你想进行一些代码审查，你可能希望打开这个警告...

- Frederik Gheysels