問題描述

自從 .net 2.0 中引入這個概念以來，我一直在尋找一些好的指導.

I've been searching for some good guidance on this since the concept was introduced in .net 2.0.

為什么我想在 c# 中使用不可為 null 的數據類型?(一個更好的問題是為什么我不默認選擇可空類型，而僅在明確有意義的情況下才使用不可空類型.)

Why would I ever want to use non-nullable data types in c#? (A better question is why wouldn't I choose nullable types by default, and only use non-nullable types when that explicitly makes sense.)

選擇可空數據類型而不是不可空數據類型是否會對性能產生重大"影響?

Is there a 'significant' performance hit to choosing a nullable data type over its non-nullable peer?

我更喜歡根據 null 而不是 Guid.empty、string.empty、DateTime.MinValue、<= 0 等檢查我的值，并且通常使用可空類型.我不經常選擇可空類型的唯一原因是我后腦勺發癢的感覺，這讓我覺得不僅僅是向后兼容性迫使額外的?"顯式允許空值的字符.

I much prefer to check my values against null instead of Guid.empty, string.empty, DateTime.MinValue,<= 0, etc, and to work with nullable types in general. And the only reason I don't choose nullable types more often is the itchy feeling in the back of my head that makes me feel like it's more than backwards compatibility that forces that extra '?' character to explicitly allow a null value.

是否有人總是(大多數情況下)選擇可空類型而不是不可空類型?

Is there anybody out there that always (most always) chooses nullable types rather than non-nullable types?

感謝您的時間，

推薦答案

你不應該總是使用可空類型的原因是有時你能夠保證一個值將被初始化.并且您應該嘗試設計您的代碼，以便盡可能經常出現這種情況.如果一個值不可能被未初始化，那么 null 就沒有理由成為它的合法值.作為一個非常簡單的例子，考慮一下:

The reason why you shouldn't always use nullable types is that sometimes you're able to guarantee that a value will be initialized. And you should try to design your code so that this is the case as often as possible. If there is no way a value can possibly be uninitialized, then there is no reason why null should be a legal value for it. As a very simple example, consider this:

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

這始終有效.c 不可能被初始化.如果它變成了一個 int?，你實際上是在告訴代碼的讀者這個值可能為空.確保在使用之前檢查它".但是我們知道這永遠不會發生，那么為什么不在代碼中公開這個保證呢?

This is always valid. There is no possible way in which c could be uninitialized. If it was turned into an int?, you would effectively be telling readers of the code "this value might be null. Make sure to check before you use it". But we know that this can never happen, so why not expose this guarantee in the code?

在值是可選的情況下，您是絕對正確的.如果我們有一個可能返回也可能不返回字符串的函數，則返回 null.不要返回 string.Empty().不要返回魔法值".

You are absolutely right in cases where a value is optional. If we have a function that may or may not return a string, then return null. Don't return string.Empty(). Don't return "magic values".

但并非所有值都是可選的.將所有內容都設為可選會使您的其余代碼變得更加復雜(它添加了另一個必須處理的代碼路徑).

But not all values are optional. And making everything optional makes the rest of your code far more complicated (it adds another code path that has to be handled).

如果你能特別保證這個值永遠有效，那為什么要扔掉這些信息呢?這就是您通過使其成為可空類型來做的事情.現在該值可能存在也可能不存在，任何使用該值的人都必須處理這兩種情況.但是您知道，首先這些情況中只有一種是可能的.所以請幫助您的代碼的用戶，并在您的代碼中反映這一事實.然后，您的代碼的任何用戶都可以依賴該值是否有效，而且他們只需處理一種情況而不是兩種情況.

If you can specifically guarantee that this value will always be valid, then why throw away this information? That's what you do by making it a nullable type. Now the value may or may not exist, and anyone using the value will have to handle both cases. But you know that only one of these cases is possible in the first place. So do users of your code a favor, and reflect this fact in your code. Any users of your code can then rely on the value being valid, and they only have to handle a single case rather than two.

這篇關于為什么我不應該總是在 C# 中使用可空類型的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！