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