コンセプトが.net2.0で導入されて以来、私はこれに関するいくつかの良いガイダンスを探してきました。
なぜc＃でnull許容でないデータ型を使用したいのですか？（より良い質問は、なぜデフォルトでnull許容型を選択せず、明示的に意味がある場合にのみnull許容型を使用しないのかということです。）
null許容でないピアよりもnull許容データ型を選択することで「重大な」パフォーマンスへの影響はありますか？
Guid.empty、string.empty、DateTime.MinValue、<= 0などではなく、nullに対して値をチェックし、一般にnull許容型を処理することをお勧めします。そして、null許容型を頻繁に選択しない唯一の理由は、頭の後ろのかゆみを感じさせることです。これは、下位互換性以上のものであり、余分な「？」null値を明示的に許可する文字。
常に（ほとんどの場合）null許容型ではなくnull許容型を選択する人はいますか？
御時間ありがとうございます、
null許容型を常に使用する必要がない理由は、値が初期化されることを保証できる場合があるためです。そして、これが可能な限り頻繁に当てはまるようにコードを設計するようにしてください。値が初期化されていない可能性がある方法がない場合、nullがその値の正当な値である必要がある理由はありません。非常に簡単な例として、次のことを考慮してください。
List<int> list = new List<int>()
int c = list.Count;
これは常に有効です。初期化されていない可能性のある方法はありませcん。に変換された場合int?、コードの読者に「この値はnullである可能性があります。使用する前に必ず確認してください」と効果的に伝えます。しかし、これは決して起こり得ないことを私たちは知っているので、なぜこの保証をコードで公開しないのですか？
値がオプションである場合、あなたは絶対に正しいです。文字列を返す場合と返さない場合がある関数がある場合は、nullを返します。string.Empty（）を返さないでください。「魔法の値」を返さないでください。
ただし、すべての値がオプションであるとは限りません。また、すべてをオプションにすると、コードの残りの部分がはるかに複雑になります（処理する必要のある別のコードパスが追加されます）。
この値が常に有効であることを明確に保証できるのであれば、なぜこの情報を破棄するのでしょうか。それはあなたがそれをnull許容型にすることによってあなたがすることです。これで、値が存在する場合と存在しない場合があり、値を使用する人は両方のケースを処理する必要があります。しかし、そもそもこれらのケースの1つだけが可能であることを知っています。したがって、コードのユーザーは好意を示し、この事実をコードに反映します。コードのすべてのユーザーは、有効な値に依存でき、2つではなく1つのケースを処理するだけで済みます。
null許容型がであるかどうかを常にチェックする必要があるのは不便だからですnull。
明らかに、値が本当にオプションである場合があり、その場合、マジックナンバーなどではなくnull許容型を使用するのが理にかなっていますが、可能な場合はそれらを避けようとします。
// nice and simple, this will always work
int a = myInt;
// compiler won't let you do this
int b = myNullableInt;
// compiler allows these, but causes runtime error if myNullableInt is null
int c = (int)myNullableInt;
int d = myNullableInt.Value;
// instead you need to do something like these, cumbersome and less readable
int e = myNullableInt ?? defaultValue;
int f = myNullableInt.HasValue ? myNullableInt : GetValueFromSomewhere();
言語設計者は、「デフォルトでnull許容である参照型」は間違いであり、null許容でないことが唯一の賢明なデフォルトであり、null許容を選択する必要があると感じていると思います。（これは、多くの現代の関数型言語での方法です。）「null」は通常、問題の山です。
2つの異なる質問があるようです...
C＃でnull許容でないデータ型を使用したいのはなぜですか？
単純です。依存している値型データは、コンパイラによって実際に値を持つことが保証されているためです。
デフォルトでnull許容型を選択せず、明示的に意味がある場合にのみnull許容型を使用しないのはなぜですか？
Joelがすでに述べたように、型は参照型である場合にのみnullになります。値型は、コンパイラーによって値を持つことが保証されています。プログラムが値を持つ変数に依存している場合、これはnull許容型を選択しないことで必要となる動作です。
もちろん、あなたのデータがあなたのプログラム以外の場所から来ているとき、すべての賭けはオフになります。最良の例はデータベースからのものです。データベースフィールドはである可能性がnullあるため、プログラム変数でこの値を模倣する必要があります。「表す」「魔法の」値（つまり、-1、0など）を作成するだけではありませんnull。これはnull許容型で行います。
null値は、「まだ初期化されていない」または「指定されていない」値として使用すると便利ですが、主にnull変数（number-or-）の意味とオーバーロードしているため、コードがより複雑になります。 null対ジャストアナンバー）。
NULL値は、多くのデータベース設計者やSQLデータベースプログラマーに好まれていますが、問題についての考え方を少し変えるだけで、null値をなくすことができ、実際には、より単純で信頼性の高いコードを使用できます（たとえば、sについて心配する必要はありませんNullReferenceException）。
実は「T！」の需要は大きいです。「T？」と同様に、参照型をnull不可にする演算子。値型をnull許容にし、C＃の発明者であるAnders Hejlsbergは、この機能が含まれていることを望みました。
私は、意味のあるところならどこでもNullable型を使用する傾向があります。問題が発生するまでパフォーマンスは気にしないので、問題が発生するいくつかの領域を修正して、それを実行します。
ただし、一般的に、私の値のほとんどはnull許容ではないこともわかりました。実際、後で使用しようとしたときではなく、nullを取得したときに、参照型で使用してnullの問題を見つけることができるNotNullableが必要になることがよくあります。
Nullable Typeを使用する必要があるのは、データベースのテーブルの特定のフィールドで、ある時点でアプリケーションがnullを送受信する必要がある場合のみです。そのような場合でも、常にNullable型を使用する方法を見つけるように努める必要があります。ブールは常にあなたの親友ではありません。