抑制静态代码分析警告 CA1806，针对 TryParse 调用

Question

我想知道人们对使用FxCop时CA1806（DoNotIgnoreMethodResults）静态代码分析警告的看法。

我有几个情况需要使用Int32.TryParse来读取保存在文件中的内部配置信息。最终我会得到很多类似以下代码：

Int32.TryParse(someString, NumberStyles.Integer, CultureInfo.InvariantCulture, out intResult);

MSDN表示如果出现错误，intResult的默认结果为零，这正是我想要的。

不幸的是，当进行静态代码分析时，此代码将触发CA1806。修复此问题需要编写大量冗余/无用代码，例如以下内容：

bool success = Int32.TryParse(someString, NumberStyles.Integer, CultureInfo.InvariantCulture, out intResult);
if (!success)
{
 intResult= 0;
}

我应该抑制这个消息还是硬着头皮添加所有冗余的错误检查？或者也许有人对处理这种情况有更好的想法？

谢谢！

- Tim

---

这个标题不合适，请使用类似于“什么时候可以忽略风格警告？”的标题并重新措辞问题。当前的状态可能会被关闭为“不是一个问题”。 - Firoso

Answer 1

为什么不将您的TryParse重构为一个函数，以实现您想要的行为呢？例如：

static int ParseOrDefault(string someStr)
{
    int result = 0;
    if(int.TryParse(someStr, out result))
    {
        return result;
    }
    return 0;
}

那样你就可以避免烦人的警告并丢掉冗余的代码。一个单独的函数使你的期望明确，并且不留任何混淆的空间。

- Corbin March

---

为什么你要使用多个返回语句？这是一种非常糟糕的编程习惯，会导致测试和重构变得困难。 - Firoso

@Firoso - 这也可以作为字符串扩展方法（命名不同）使用。多个返回语句对我来说并不麻烦，特别是在一个简短的函数中。Bruce Eckel 似乎也不介意它们：http://onthethought.blogspot.com/2004/12/multiple-return-statements.html。但如果你不喜欢它们，请务必避免使用它们。 - Corbin March

Answer 2

咬紧牙关，或者至少添加注释。 Johnny the Homicidal coder 怎么知道 Int32.TryParse 将提供 0 输出而不查看外部文档？ 同样，他怎么知道 0 是您想要的默认值？ 后面的实现在其目的上是具体的，因此我必须同意 FxCop 的观点。

记住，Johnny 知道你住在哪里。

话虽如此，我经常抑制 StyleCop（主要是因为我使用异步 CTP，它们还不能很好地一起工作）。 样式指南只是指南。 使用头脑，但如果性能不是问题，请始终偏向于清晰度。

请记住，这种行为可能会在将来更改，您是否总是希望 0 成为默认值？ 这可以改变吗？ 即使您重构为 ParseOrDefault 帮助程序，您也应该考虑产品生命周期中合理的默认更改。

- Firoso

---

如果Johnny熟悉C#，他会知道这一点，因为调用的方法必须为使用out修饰符声明的任何参数分配一个值。这与Int32.TryParse没有什么特别之处。 - Fredrik Mörk

除了Int32.TryParse分配为0仍然是特定的（尽管常见）到那个方法之外，还有谁说Johnny很能干？;-) 他只是有杀人倾向的。 - Firoso

true，值为“0”是特定于“TryParse”的。而且“homicidal”是一个相当强烈的论点 :o) - Fredrik Mörk

Answer 3

抑制它！

FxCop/Code Analysis只是一些指南。它可以帮助改进代码的某些部分，特别是如果代码将被分发给其他开发人员使用，但归根结底，它只是一个指南，您可以按照自己的喜好编码。

- Alastair Pitts