為什么我不總是在C＃中使用可為空的類型

Question

自從.net 2.0中引入此概念以來，我一直在尋找有關此問題的良好指導。

為什么我要在c＃中使用不可為空的數據類型？ （一個更好的問題是，為什么我默認情況下不選擇可空類型，而只在明確有意義的情況下才使用非空類型。）

選擇非空對等數據類型的可空數據類型是否會對性能產生重大影響？

我更喜歡針對null而不是Guid.empty，string.empty，DateTime.MinValue，<= 0等檢查我的值，並且通常使用可為null的類型。 我不經常選擇可為空的類型的唯一原因是我的后腦發癢，這讓我感覺不僅僅是向后兼容會導致額外的“？” 字符，以明確允許空值。

有沒有人總是（最經常）選擇可空類型而不是非可空類型？

謝謝你的時間，

Answer 1

之所以不總是使用可為空的類型，是因為有時您可以保證將初始化一個值。 而且，您應該嘗試設計代碼，以便盡可能多地出現這種情況。 如果無法對值進行初始化，則沒有理由為什么null應該是合法值。 作為一個非常簡單的示例，請考慮以下問題：

List<int> list = new List<int>()
int c = list.Count;

這始終是有效的。 沒有任何可能的方法可以初始化c 。 如果它變成一個int? ，您實際上會告訴代碼的讀者“此值可能為null。使用前請務必進行檢查”。 但是我們知道這永遠不會發生，那么為什么不在代碼中公開這種保證呢？

如果值是可選的，那么您絕對正確。 如果我們有一個可能會或可能不會返回字符串的函數，則返回null。 不要返回string.Empty（）。 不要返回“魔術值”。

但並非所有值都是可選的。 並且使所有內容都可選，使其余代碼變得更加復雜（它增加了另一個必須處理的代碼路徑）。

如果可以明確保證此值始終有效，那么為什么要丟棄此信息呢？ 這就是使它成為可為空的類型的方法。 現在，該值可能存在或不存在，並且使用該值的任何人都必須處理這兩種情況。 但是您知道，首先這些情況只有一種可能。 您的代碼用戶也是如此，並在您的代碼中反映這一事實。 然后，您的代碼的任何用戶都可以依靠該值是否有效，而他們只需要處理一個個案而不是兩個個案。

Answer 2

因為總是必須檢查可空類型是否為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();

Answer 3

我認為語言設計人員認為“引用類型默認情況下可為空”是一個錯誤，並且非空值是唯一明智的默認值，因此您應該選擇使用空值。 （這在許多現代功能語言中都是這樣。）“空”通常是一堆麻煩。

Answer 4

您似乎有2個不同的問題...

為什么我要在C＃中使用不可為空的數據類型？

很簡單，因為編譯器保證您所依賴的值類型數據實際上具有值！

為什么我默認不選擇可為空的類型，而僅在明確有意義的情況下才使用非可為空的類型？

正如Joel已經提到的那樣，如果類型是引用類型，則只能為null。 編譯器保證值類型具有值。 如果您的程序依賴於變量具有值，則這是您不選擇可為空的類型所希望的行為。

當然，當您的數據來自不是程序的任何地方時，所有的賭注都關閉了。 最好的例子是來自數據庫。 數據庫字段可以為null ，因此您希望您的程序變量模仿該值-不僅僅是創建“代表” null的“魔術”值（即-1、0或其他null 。 您可以使用可為空的類型。

Answer 5

盡管null值可以方便地用作“ not-initialized-yet”或“ not-specified”值，但它們會使代碼更加復雜，這主要是因為您正在重載null的含義以及變量（數字或-null與。

NULL值受到許多數據庫設計人員和SQL數據庫程序員的青睞，但是在思考問題上所做的更改很小，您可以消除null值，而實際上擁有更簡單，更可靠的代碼（例如，不必擔心NullReferenceException ）。

實際上，對“ T”的需求很大。 使得任何引用類型都不能為空的運算符，類似於“ T？” 使值類型可為空，C＃的發明者Anders Hejlsberg希望他包括該功能。

另請參閱問題， 為什么C＃和Java中存在“空”？

Answer 6

我傾向於在任何有意義的地方使用Nullable類型-在出現問題之前我不會在意性能，然后我將修復其中的少數問題並加以解決。

但是，我還發現，總的來說，我的大多數價值觀最終都是不可為空的。 實際上，實際上我有很多次想要一個NotNullable，我可以將其與引用類型一起使用，以便在我得到null時發現有關null的問題，而不是稍后再嘗試使用它時。

Answer 7

只有在數據庫表中的某個字段絕對要求應用程序在某個時候發送或接收null的情況下，才應使用Nullable Type。 即使在這種情況下，也應該始終設法找到一種使用Nullable Type的方法。 布爾並不總是您最好的朋友。