问题描述

自从 .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# 中使用可空类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！