問題描述

自從 .net 2.0 中引入這個(gè)概念以來(lái)，我一直在尋找一些好的指導(dǎo).

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

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

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.)

選擇可空數(shù)據(jù)類型而不是不可空數(shù)據(jù)類型是否會(huì)對(duì)性能產(chǎn)生重大"影響?

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

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

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.

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

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

感謝您的時(shí)間，

推薦答案

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

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 不可能被初始化.如果它變成了一個(gè) int?，你實(shí)際上是在告訴代碼的讀者這個(gè)值可能為空.確保在使用之前檢查它".但是我們知道這永遠(yuǎn)不會(huì)發(fā)生，那么為什么不在代碼中公開這個(gè)保證呢?

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?

在值是可選的情況下，您是絕對(duì)正確的.如果我們有一個(gè)可能返回也可能不返回字符串的函數(shù)，則返回 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".

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

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).

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

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.

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