在为我正在从事的一个小项目使用代码分析之后，我想知道在解析代码以符合分析要求时我应该有多严格。
我知道我可以为此禁止警告，但对我来说，在某种程度上禁止警告是一种逃避（不是双关语......“FXCop”）。
示例警告：
不要在意外位置引发异常“CustomObject.Equals(object)”会创建“ArgumentException”类型的异常。在这种类型的方法中不应引发异常。如果可能引发此异常实例，请更改此方法的逻辑，使其不再引发异常。
扔这个的原因...
CustomObject.Equals(object) 可能会尝试将 CustomObject 与 FooBarObject 进行比较......它们甚至不是同一类型，所以在这种情况下，我应该抛出异常，还是只返回 false？
一般来说，我是否真的应该（因为想要一个更好的词）使我的代码绝对合规，或者我会遇到需要警告抑制的情况？
FxCop 警告只是警告，它们不会标记无效代码。这就是编译器的工作。FxCop 使用的规则是从多年编写 .NET 代码的经验中收集的。它们代表“最佳实践”，并且通常会提醒您意想不到的后果以及 .NET 编程中更晦涩的部分，例如 CAS。
始终参考文档以了解规则存在的原因。对于 CA1065，您将看到：
Equals 方法应该返回 true 或 false 而不是抛出异常。例如，如果 Equals 传递了两个不匹配的类型，它应该只返回 false 而不是抛出 ArgumentException。
完全符合您的使用情况，您可以轻松采纳建议。不幸的是，创建规则的确切原因有点短。这真的没有超出“不要扔在意想不到的地方”的指导。这里的意外后果是，另一个使用您的类的程序员不会意识到如果他不希望代码失败，则需要尝试/捕获。随意将 Debug.Assert() 放入您的 Equals 方法中。在很多情况下，您会希望忽略这些建议，例如 CA2000 特别容易出现错误警告。必要时应用 [SuppressMessage] 属性，不必再次查看它。