我最近将我的项目从 Visual Studio 2008 升级到 Visual Studio 2010。
在 Visual Studio 2008 中，此代码分析规则不存在。
现在我不确定我是否应该使用这条规则。
我正在构建一个开源库，所以让人们避免犯错似乎很重要。但是，如果我要做的只是ArgumentNullException在参数为 时抛出null，这似乎是在编写无用的代码，因为ArgumentNullException即使我不编写该代码也会被抛出。
编辑：另外，还有一个性能问题需要解决。null在每个公共方法中检查可能会导致性能问题。
我应该删除该规则还是修复违规行为？
那要看。使用 ArgumentNullException 时的约定是在描述中包含 null 参数的名称。所以调用者会确切地知道出了什么问题。
NullReferenceException 的来源（如果您不验证会发生这种情况）可能很容易发现，但如果方法很复杂，则可能会更加困难。您最终可能会遇到多个引用可能为空的代码行。
就我个人而言，如果公共方法无法处理给定参数的空输入，我更喜欢让公共方法抛出 ArgumentNullException，因为无论方法如何实现，它都允许一致的行为。
回复编辑：在我看来，提供一组一致的接口比优化每一行代码更重要。我的猜测是，在大多数情况下，null 检查的性能开销不会很大。如果它确实是一个问题（如分析中所说），我会考虑改变它。否则我现在不会认为这是一个问题。
我们保留这条规则是因为我们认为最好在参数第一次进入您的代码时检查它们。这样，当使用您的代码的人收到异常时，其中的上下文会更好。例如，没有您的源代码的人会看到您的代码中引发了异常，并且可能会向您提交错误报告，因为它浪费了您和他们的时间。
恕我直言，没有。检查空值几乎永远不会成为应用程序的性能瓶颈。（在百万分之一的情况下，它很重要，你会用你的分析器找到它并删除那个情况）。
您脑海中应该形成的另一个问题是“ throw new NullReferenceException() 真的是处理错误的最佳方法吗？” 通常，您可以处理得比这更好（即使只是为了向用户和/或您自己提供更好的错误报告以进行调试）。在许多情况下，代码可以优雅地处理空值，这根本不需要成为错误。
编辑
回答您的编辑：空检查确实不需要很长时间。简单地调用一个方法的开销将是空检查的数十倍甚至数百倍。空检查会产生任何显着差异的唯一地方是在一个大而紧密的循环中，您几乎没有做其他事情。这种情况不会经常发生——通常你会检查一个空值，然后用那个引用做一些相对昂贵的事情。
没有任何情况下崩溃或失败是一件好事。使用空检查“减慢您的应用程序”总是比崩溃和丢失客户数据要好。
所以不要过早地优化你的代码。写得好，使其可维护和健壮，然后对其进行分析以查看瓶颈在哪里。我已经编程了 28 年，对空值检查非常自由，并且从未发现空值检查是导致性能问题的原因。通常是在循环中做很多不必要的工作，使用 O(n^3) 算法，其中 O(n^2) 方法是可能的，未能缓存昂贵的计算值等。