为什么我不应该总是在C#中使用可空类型

Mat*_*nes 35 c# null nullable c#-2.0

自从这个概念在.net 2.0中引入以来,我一直在寻找一些很好的指导.

为什么我要在c#中使用不可为空的数据类型?(一个更好的问题是为什么我不能默认选择可空类型,只有在明确有意义时才使用非可空类型.)

在其非可空对等体上选择可空数据类型是否会产生"重大"性能影响?

我更喜欢检查我的值而不是Guid.empty,string.empty,DateTime.MinValue,<= 0等,并且通常使用可空类型.而且我不经常选择可空类型的唯一原因是我脑后的痒感使我觉得它不仅仅是向后兼容性而是强迫额外的'?' 要明确允许空值的字符.

是否有人总是(最常见的)选择可空类型而不是非可空类型?

谢谢你的时间,

jal*_*alf 46

您不应该总是使用可空类型的原因是,有时您可以保证初始化值.你应该尝试设计你的代码,以便尽可能经常这样.如果某个值无法被初始化,那么就没有理由认为null应该是一个合法的值.作为一个非常简单的例子,考虑一下:

List<int> list = new List<int>()
int c = list.Count;
Run Code Online (Sandbox Code Playgroud)

始终有效.没有可能c未初始化的方式.如果它变成了一个int?,你会有效地告诉读者代码"这个值可能是null.确保在使用它之前检查".但我们知道这种情况永远不会发生,为什么不在代码中公开这种保证呢?

在值是可选的情况下,您绝对正确.如果我们有一个可能会或可能不会返回字符串的函数,则返回null.不要返回string.Empty().不要回归"神奇的价值观".

但并非所有值都是可选的.并且使一切都是可选的使得代码的其余部分变得更加复杂(它增加了另一个必须处理的代码路径).

如果您可以特别保证此值始终有效,那么为什么要丢弃这些信息呢?这就是你通过使它成为可以为空的类型所做的.现在值可能存在,也可能不存在,使用该值的任何人都必须处理这两种情况.但是你知道,首先只有其中一种情况可能发生.您的代码用户也应该受到青睐,并在您的代码中反映这一事实.然后,您的代码的任何用户都可以依赖有效的值,并且他们只需要处理单个案例而不是两个案例.

  • 如果我们获得Spec#功能将引用类型声明为非可空,那不是很酷吗?`string!`然后代表一个不可能为null的字符串. (5认同)
  • 我认为同样的经验法则适用于那里.您能保证酒店永久有效吗?(你的对象可能总是有一个ID,所以没有必要使那个可以为空.但是其他属性可能存在也可能不存在,具体取决于对象的状态.但请记住*if*你可以使一个值不可为空,这使得将来使用它变得更好,因为用户不必对null进行检查.所以看看是否可以保证属性是有效的,如果可以的话,不要让它可以为空. (2认同)

Luk*_*keH 9

因为总是必须检查可空类型是否不方便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();
Run Code Online (Sandbox Code Playgroud)