我针对我创建的对象运行了 VS 2008 代码分析工具，并收到了以下建议...
警告 147 CA1021：Microsoft.Design ：考虑一种不 要求 'returnValue' 为 out 参数。
我发现“out”参数相当有用，但没有意识到它们被认为是不受欢迎的设计实践。我想知道是否有人可以解释我收到此警告的原因？如果这是不好的做法？为什么？什么是好的做法？
我很感激任何建议。
每个代码分析警告都有关联的文档，您可以通过突出显示警告并按 F1 来访问这些文档。您还可以右键单击该项目来获取帮助。
无论如何，这里有 解释该特定警告的文档。
我想说，在某些情况下，out 参数仍然是一个不错的选择 - 特别是当涉及到 TryParse 编码习惯时，因为它是一种行之有效的做事方式，大多数人都应该理解它
但是，在一般使用中，对于多个返回值，有更好、更面向对象的解决方案。
我曾经对我的项目进行过代码分析。我也确实得到了很多有见地的建议，我非常短暂地将其关闭。许多建议都具有宗教性质，您可以这样或那样做，只是风格问题而不是坏习惯。
根据你的情况。如果只有一个返回参数，则将其从函数中返回。
如果你还有一个返回码占用了返回位置，可以考虑使用异常来通知调用者代码操作错误。
如果要返回许多彼此密切相关的参数，请创建一个类/结构将它们组合在一起并将其作为一个包返回。
在我看来，许多代码分析警告都与编写第三方将使用的 API 代码相关。您使用“out”参数的规则是一个经典案例：不使用它们的部分原因是因为许多其他程序员不知道它们。
如果它们与您正在编写的内容不匹配，请关闭不适合您的代码分析规则。 就我个人而言，我倾向于关闭命名、可移植性和互操作性规则，因为它们与我编写的代码类型无关。
我在我的大多数项目中都关闭了这个特定的警告。 因为，我知道，当我使用 out 参数时，我有充分的理由这样做，因为我试图完全避免它们。
我可以想象，当与多个人一起处理一个项目时，如果您想做一些代码审查，您可能希望打开此警告......
在 Net5 及更高版本中，即使您设置
AnalysisMode to AllAnalysisLevel to latest-all使用规则 CA1021 的唯一方法是使用
dotnet_diagnostic.CA1021.severity = <severity> entry此外，该规则可能会在未来版本中被弃用 （正如 dotnet 分析器团队所说）.
了解更多详情阅读