C# 8 - 可空引用类型

微软正在为 C# 8 添加一个名为可空引用类型的新功能。乍一看这很令人困惑，因为所有引用类型都是可空的……那么这有什么不同呢？从现在开始，如果启用了此功能，引用类型将是不可空的，除非您明确将它们标注为可空。

让我来解释一下。

可空引用类型

当启用可空引用类型并且编译器认为引用类型有可能为 null 时，它会警告您。您会在 Visual Studio 中看到警告消息：

以及构建警告：

要移除此警告，请在引用类型后面添加一个问号。例如：

public string StringTest()
{
    string? notNull = null;
    return notNull;
}

现在引用类型的行为就像 C# 8 之前一样。

此功能通过在任何 C# 文件顶部添加 <span class="inline-code"> #nullable enable </span> 或在 .csproj 文件中添加 <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> 来启用。默认情况下它不会启用，这是件好事，如果启用的话，任何现有的代码库都可能像圣诞树一样亮起来。

Null 争论

为什么微软现在要添加这个功能？Null 从语言诞生之初就是其一部分了？老实说，我不知道为什么。我一直在使用 null，这是 C# 中的生活现实。我没有意识到不使用 null 是一个选择……也许没有它们的生活会更好。我们会发现的。

您应该还是不应该使用 null？我总结了我所理解的持续争论。

支持方

支持 null 的论点通常是对象具有未知状态。这种未知状态用 null 表示。您可以在 SQL Server 的 bit 数据类型中看到这一点，它有 3 个值：null（未设置）、0 和 1。您也可以在 UI 中看到这一点，有时知道用户是否触摸了某个字段很重要。有人可能会反驳说：“为什么不创建一个未知状态类型或’未设置’状态，而不是使用 null？“这与 null 有什么不同？您仍然需要检查这个额外的状态。现在您要为每个实例创建未知状态。为什么不直接使用 null 并拥有一个全局未知状态呢？

反对方

反对 null 的论点是它是一种不同的数据类型，每次使用引用类型时都必须检查它。最终结果是这样的代码：

var user = GetUser(username, password);

if(user != null)
{
    DoSomethingWithUser(user);
} else 
{
    SetUserNotFoundErrorMessage()
}

如果 GetUser 方法在所有情况下都返回用户，包括找不到用户时。如果代码从不返回 null，那么防范它就是浪费，理想情况下，这简化了代码。但是，在某些时候，您需要检查空用户并显示错误消息。不使用 null 并不能消除处理找不到用户这一业务情况的需要。

这个功能是好主意吗？

此功能的目的不是消除 null 的使用，而是提出问题：“有更好的方法吗？“有时答案是”没有”。如果我们能够通过一点预先考虑来消除对 null 的持续检查，进而简化我们的代码。我支持。好消息是 C# 已经让处理 null 变得微不足道。

我确实担心有些人会采取教条主义立场，坚持消除 null 而损害系统。这是徒劳的努力，因为 null 是 C# 不可分割的一部分。

可空引用类型是个好主意吗？如果最终结果是更简单、更少出错的代码，那就是。