15

私が String.IsNullOrEmpty を Session 変数で誤用した職場での事件の後、私の仲間の同僚は、私の String.IsNullOrEmpty の使用を受け入れることを拒否しました。いくつかの調査の後、どうやら MSDN の IsNullOrEmpty にリストされているバグがあるようです (リンク) (下部のメモを読んでください):

2006 年 4 月 4 日の時点で、最適化がオンになっているとこのメソッドが失敗するバグ (JIT で発生する可能性があります) があります。C# と VB の両方に影響することが知られています。

詳細については、こちら (リンク) を参照してください。マイクロソフトのバグは「おそらく」Orcas 後に修正されていますが、残念ながら私の雇用主はまだ VS2005 を使用しています。しかし、2008年以降に問題が修正されれば、それで問題ありません。それは私には問題ありません。

私の同僚がIsNullOrEmptyを使用して私のコードを拒否したことは盲目的な無知(IMO)ですが、セッション変数の誤用以外に使用しない理由を彼は確かに教えてくれません。コード全体で IsNullOrEmpty を使用しましたが、問題はありません。個人的には、1 つのステートメントで 2 つのことを行うことに加えて、はるかに読みやすいと思います。

この件に関する意見をグーグルで検索した後、賛否両論のサイトを見つけました。これについて私が読んだサイトのいくつかを次に示します。

https://blog.rthand.com/post/2006/06/22/1063.aspx

http://www.omegacoder.com/?p=105

1 つのサイト ( http://dotnetperls.com/isnullorempty ) は、この方法 (IMHO) をかなりうまくまとめています。

ここでは、文字列型の IsNullOrEmpty メソッドを調べました。これは、文字列を保存または使用してもよいかどうかを確認するための優れた比較的効率的な方法を提供します。ただし、パフォーマンスのためには、手動の null チェックを使用する方がよい場合があります。空の文字列は他の方法でもテストできます。ここでの私の調査では、長さをチェックするのが最も速いことが示されています。

バグ修正が VS2008/2010/etc に適用されている (そして正しく動作している) と仮定すると、VS2005 以降で String.IsNullOrEmpty を使用しない理由はありますか? これは、このようなばかげた小さな方法では少しやり過ぎに思えるかもしれませんが、舞台裏でさらに多くのことが起こっているかどうか、誰かが別の説明を持っているかどうかを知りたいです.

4

10 に答える 10

24

この問題は、.NET 2.0 sp1 で修正されました。現在、その使用を避ける理由はありません。

.NET 2 を使用している場合は、とにかく他の多くの理由で sp1 を使用する必要があります。もはや存在しないバグのためにこれを回避する理由はありません。

于 2009-11-06T22:40:46.160 に答える
5

私は以前にそのバグについて聞いたことがありますが、収集できる限り、実際のコードでは発生せず、実際には何もしない例のようなコードでのみ発生します。また、バグは IsNullOrEmpty メソッド自体にあるものではないため、どのように文字列を確認しても発生します。

メソッドがまさにやりたいことを実行する場合は、それを使用する必要があります。ただし、空の文字列をチェックするためにすべての状況で使用する必要はありません。場合によっては、文字列が空かどうかのみをチェックし、null かどうかをチェックしたくないことがあります。

文字列変数が null の場合、これはコード ブロックをスキップします。

 if (!String.IsNullOrEmpty(str)) { ... }

文字列変数が null の場合、例外が発生します。

 if (str.Length > 0) { ... }

変数が null であってはならない場合は、null 値を空の文字列として扱うコードではなく、おそらく例外が必要です。何か問題がある場合は、できるだけ早くそれをキャッチする必要があります。原因からの例外が長くなるほど、問題をソースまで追跡するのが難しくなるためです。

于 2009-11-06T22:47:05.630 に答える
4

空の文字列を渡す単体テストと null 文字列を渡す単体テストを記述して、これをテストし、VS2005 以降で実行して 2008 年に実行して、何が起こったかを確認できます。

于 2009-11-06T22:42:14.410 に答える
3

次の拡張メソッドを使用しますstring.IsNullOrEmpty

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

このアプローチを使用すると、以前のバージョンで壊れていたとしても、バグ修正は 1 行のコードで済みます。

また、null の可能性がある文字列インスタンスでメソッドを使用できるという追加のユーティリティ:

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}
于 2009-11-06T22:47:00.523 に答える
3

リンクに含まれるそのバグレポートには、次のように記載されています。

このバグは、Microsoft .NET Framework 2.0 Service Pack 1 (SP1) で修正されました。

そのため、.NET 2 の SP1 がインストールされている限り、VS 2005 を使用しているかどうかは問題ではありません。

使用するかどうかについては、CodingHorror によるこの投稿を確認してください。

于 2009-11-06T22:42:44.100 に答える
2

API で引数チェックを実装する場合、通常は各条件を個別にチェックし、さまざまな例外をスローArgumentNullExceptionします (null 参照の場合、または API 仕様によってArgumentExceptionは空の文字列の場合)。この場合、 を使用String.IsNullOrEmptyしても、これら 2 つの別個のエラー状態を区別することはできません。

if (str == null)
{
    throw new ArgumentNullException("str");
}
if (str == string.Empty)
{
    throw new ArgumentException("The string cannot be empty.", "str");
}
于 2010-02-03T18:54:05.957 に答える
1

SP1で修正されたと確信していますが、とにかく独自のnullまたは空のメソッドを作成できます:)

于 2009-11-06T22:43:48.640 に答える
1

他の言語やその一部と同様に、長所と短所を知り、その情報に基づいて知識に基づいた決定を下すことがすべてです。私見では。

于 2009-11-06T22:45:11.983 に答える
0

バージョンで壊れている場合は、チェックを行う静的メソッドを用意するのは簡単なので、次のようにします。

public static bool isNull(String s) {
  return s == null || s.trim().length == 0;
}

比較的簡単に修正できるはずのものをめぐって大きな問題に巻き込まれても意味がありません。

ある静的メソッドを別の静的メソッドにグローバルに置き換えることはできますが、どこでも変更する必要はありません。

于 2009-11-06T22:40:56.080 に答える
-5

なぜ人々はstring.Emptyを使用するのだろうか、それは初期化された文字列であり、この概念はどこでも.Netフレームにのみ存在するため、良いことではありません。 null をチェックするロジックがあるが、空の文字列を取得する場合)。string.IsNullOrEmpty は、私が今まで見た中で最悪のプラクティス/関数のトップ 5 の 1 つだと思います。なぜなら、どういうわけか、人々が文字列を初期化することを奨励/正常に見せ、null として扱うことができるからです。この関数は決して追加されるべきではなかったので、.Net 関係者はそれを段階的に廃止しようとするべきだと思います :) とにかく空の文字列が必要なのは誰ですか? 既存のプロジェクトで使用されているため、必要がない限り使用したことはありません

于 2010-02-03T18:43:08.697 に答える