最近、プロジェクトをVisualStudio2008からVisualStudio2010にアップグレードしました。
Visual Studio 2008では、このコード分析ルールは存在しません。
このルールを使うべきかどうかわかりません。
私はオープンソースライブラリを構築しているので、人々が間違いを犯さないようにすることが重要だと思われます。ただし、ArgumentNullExceptionパラメータがのときにスローするだけの場合は、コードを記述しなくてもスローされるnullため、役に立たないコードを記述しているように見えArgumentNullExceptionます。
編集：また、対処する必要があるパフォーマンスの問題があります。nullすべてのパブリックメソッドをチェックすると、パフォーマンスの問題が発生する可能性があります。
そのルールを削除するか、違反を修正する必要がありますか？
場合によります。ArgumentNullExceptionを使用する場合の規則は、説明にnull引数の名前を含めることです。したがって、発信者は何が悪かったのかを正確に知ることができます。
NullReferenceExceptionのソース（検証しない場合に発生する）は簡単に見つけることができますが、メソッドが複雑な場合はさらに困難になる可能性があります。複数の参照がnullになる可能性のあるコード行になってしまう可能性があります。
個人的には、メソッドがどのように実装されていても一貫した動作が可能になるため、指定された引数のnull入力を処理できない場合は、パブリックメソッドにArgumentNullExceptionをスローさせることを好みます。
編集への返信：私の意見では、コードのすべての行を最適化するよりも、驚きの少ない一貫したインターフェイスのセットを提供することが重要です。私の推測では、ほとんどの場合、ヌルチェックのパフォーマンスオーバーヘッドは重要ではありません。それが問題であることが判明した場合（プロファイリングでそう言われているように）、私はそれを変更することを検討します。そうでなければ、現時点では問題とは思わないでしょう。
コードへの最初のエントリでパラメータをチェックすることが常に最善であると判断したため、このルールを維持します。そうすれば、あなたのコードを使用している人が例外を受け取ったときに、その中のコンテキストがより良くなります。たとえば、あなたのソースコードを持っていない人は、あなたのコードで例外がスローされたことを確認し、あなたの時間と彼らの時間を無駄にしているためにあなたに対してバグレポートを提出するかもしれません。
IMHOいいえ。nullのチェックがアプリケーションのパフォーマンスのボトルネックになることはほとんどありません。（そして、それが重要である100万件に1件の場合、プロファイラーでそれを見つけて、その1件を削除します）。
頭に浮かぶべきもう1つの質問は、「新しいNullReferenceException（）をスローすることが、エラーを処理するための本当に最良の方法ですか？」です。多くの場合、それよりもうまく処理できます（デバッグ目的でユーザーや自分自身により良いエラーレポートを提供する場合でも）。多くの場合、コードはnullを適切に処理できるため、これがエラーになる必要はまったくありません。
編集
あなたの編集に答えるには：ヌルチェックは本当に長くはかかりません。メソッドを呼び出すだけのオーバーヘッドは、ヌルチェックの数百倍ではないにしても数十倍になります。ヌルチェックが大きな違いを生む唯一の場所は、他にほとんど何もしていない大きくてタイトなループです。この状況はあまり頻繁には発生しません。通常、nullをチェックしてから、その参照を使用して比較的高価な処理を実行します。
クラッシュや失敗が良いことであるという状況はありません。クラッシュして顧客のデータを失うよりも、nullチェックを使用して「アプリケーションの速度を落とす」方が常に優れています。
したがって、コードを時期尚早に最適化しないでください。保守可能で堅牢になるように適切に記述してから、プロファイルを作成してボトルネックがどこにあるかを確認します。私は28年間プログラミングを行っており、ヌルチェックを非常に自由に行っていますが、ヌルチェックがパフォーマンスの問題の原因であることに気づいたことはありません。通常、ループ内で多くの不要な作業を行う、O（n ^ 2）アプローチが可能なO（n ^ 3）アルゴリズムを使用する、計算コストの高い値をキャッシュできないなどのようなものです。