.NET 6 中不使用可空属性是个坏习惯吗？

问题

Reddit 中有这样一个讨论：

意为：

我真的很喜欢新的.NET 版本，其中一个例外。创建新项目时，我要做的第一件事是在项目设置中禁用可为 null 的属性：

<nullable>disable</nullable>

我只是不喜欢有一个？在我所有普通对象数据类型的后面。在以前的.NET 版本中，所有类对象（不是结构）都是默认可空的。现在，如果我想要这种特性，我必须手动设置该属性。我觉得我不应该这样做，不然为什么默认情况下会启用该属性。

讨论

这里翻译几个高亮回答：

A:

从根本上讲，使用可空引用类型更好，因为它更清晰地展示了您的意图。它迫使您更多地思考对象可以处于什么状态，并限制出现空引用异常的情况。

你真的不应该在所有类型后面加上？，因为一般而言，你想尽可能防止引用变为可空。每个额外的可空类型都意味着必须更频繁地检查空，甚至更糟的是，不检查它会得到更多的异常。

尽管如此，在 C＃中存在这一功能之前已经编写了大量软件，它们大部分都很好用。如果你真的不喜欢它，我会说关闭它没关系。我工作的大多数软件也不使用它，仅仅是因为它以前不存在，并且对于大型现有应用程序启用它意味着大量乏味的重构（大多数客户不会支付）。

但是，如果您开始在使用它的公司工作，您将不得不使用它，在这种情况下，了解它的工作原理和使用原因是很好的。如果您只是一个业余程序员，请随意做。

B:

我喜欢明确的可空引用类型。它使我的代码更容易理解，因为我不必（也不会）一直担心对象为空。在我希望对象为空的情况下，它非常明确，并迫使我处理它。这真正是我喜欢它的优点。因为不这样做可能使您陷入获得令人恐惧的空引用异常的情况。这将导致您的代码库充满了永远不会发生的情况的空检查。

C:

听起来你可能误解了这个功能。您不必在所有类实例后面添加？。事实上，大多数类实例都不需要它。只有在程序逻辑中实例可能为空的情况下才需要添加它。而不是表示类型本身可为空。假设您不喜欢空检查和到处都是空返回，这是从编译器获得帮助的好方法，指示您哪里可能有可能的问题。并且只在实际上您希望返回空时使用？。

......

总结

对于 C# 中的可为 null 类型特性，不同的程序员可能有不同的看法。一方面，使用可为 null 类型特性可以使代码更易于理解，因为它可以强制开发人员考虑对象可能处于什么状态，并限制可能发生空引用异常的情况。因此，使用可为 null 类型特性可以使代码更安全。

然而，在已有的软件中启用该特性可能需要大量的重构工作，并且大多数客户不会为此支付额外的费用。对于已有的软件，大多数程序员不会选择启用该特性。

对于业余程序员，是否使用该特性完全取决于个人喜好。如果你是一个专业的程序员，并在使用该特性的公司工作，则必须使用该特性。在这种情况下，了解该特性的工作原理和使用方法是非常重要的。

总之，使用 C# 的可为 null 类型特性是一个个人选择。如果你喜欢编写明确的代码，并希望避免空引用异常，那么使用该特性是一个不错的选择。但是，如果你不喜欢使用该特性，那么也可以选择不使用它。最终决定权在你自己手中。

附上微软官方文档对可为null类型的解释：https://learn.microsoft.com/zh-cn/dotnet/csharp/nullable-references