使用Nullable<；T>；具有值类型

本文关键字：类型 Nullable lt 使用 gt | 更新日期: 2023-09-27 18:21:53

对于允许值类型为null类型的代码来说，维护是否会成为一场噩梦？我意识到int?相当于Nullable<int>，但我的问题更倾向于它的可用性。我们看到值类型，自然会忽略它们，因为它们不允许null。但引入带有问号缩写的Nullable<T>，它的作用很明显，但并不总是引人注目。

这是不是因为可以就意味着应该？

偏好应该是什么？值类型的默认值（即int SomeConfigOption = -1;）或使用Nullable<T>（即int? SomeConfigOption;）？

使用Nullable<；T>；具有值类型

偏好应该是什么？值类型的默认值（即。int SomeConfigOption=-1；）或使用Nullable（即int？SomeConfigOption；）？

在这种情况下，很明显，无论何时，只要您必须说明值的不存在，您都需要Nullable<T>。像-1这样的神奇数字是一场更糟糕的维护噩梦。

这是C#语言的一个核心功能，与其他功能一样，它可能会被滥用，但它也提供了明显的好处——这些好处远远超过了不精通该语言的人在阅读源代码时可能遇到的任何问题——是时候跟上进度了。

我认为Nullable看起来不错：具有Nullable类型的代码是完全自我文档化的。

示例：

int? someConfigOption;
if (someConfigOption.HasValue)
{
    // Use someConfigOption.Value property.
}
else
{
    // Value is absent.
}

另一种方便的方法：

int value = someConfigOption.GetValueOrDefault();

当然，以Nullable值作为参数的方法应该有良好的文档记录。

我更喜欢可为null的类型，而不是具有默认值的值类型（开发人员表示为null）。我在代码中发现了更多的问题，默认值被用来表示什么都没有。

当"null"是有效值时，应使用可为null的类型。如果null是一个有效的值，那么使用可为null的类型是一个很好的做法。但是，如果可为null的值无效，那么携带null值是不好的做法。

假设一个函数GetClientID，其中该函数从DB中读取并返回一个ClientID。让我们假设GetClientID永远不应该返回NULL或空。

从数据库读取值时，可为null的类型是处理数据库中可能的null的最佳实践。因此，GetClientID应该使用可为null的类型来正确处理异常情况（失败/日志记录等），并确保只返回有效值。

最糟糕的做法是返回一个可以为null的类型。您可能携带一个已经无效的值，该值将在代码中的某个位置读取，在加载无效值的地方发生故障（并成为维护噩梦）。

因此，问问自己，如果null值是一个有效值（有效值不尽可能相同），并相应地编码。

相关文章：