使用Nullable <t>和值类型的不良做法？</t>

Question

维护是否会成为允许可以为类型的值类型的代码的噩梦？我意识到int?相当于Nullable<int>，但我的问题更倾向于它的可用性。我们看到价值类型并自然忽略它们，因为它们不允许null。但是用问号的简写引入Nullable<T>，它显然是什么，但并不总是引人注目。

这些功能之一只是因为你可以这样做，并不意味着你应该吗？

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

Answer 1

  

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

在这种情况下，只要您遇到必须考虑值的 缺席 的情况，您就希望Nullable<T>。像-1这样的魔术数字是一个更糟糕的维护噩梦。

这是C＃语言的核心功能，与其他功能一样，它可以被滥用，但它也提供了明显的好处 - 这些好处远远超过任何不熟悉该语言的人可能已阅读源代码 - 时间到快点。

Answer 2

我认为Nullable看起来不错：具有Nullable类型的代码非常自我记录。

示例：

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

另一种方便的方法：

int value = someConfigOption.GetValueOrDefault();

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

Answer 3

我更喜欢可空类型到具有默认值的值类型（开发人员则表示为null）。我在代码中发现了更多问题，其中默认值用于什么都没有。

Answer 4

当“ null”为有效值时，应使用可空类型。如果null为有效值，则使用可空类型是一个好习惯。但是，如果可为空的值无效，那么不好的做法就是携带空值。

假设一个函数Ge​​tClientID，该函数从数据库中读取并返回一个ClientID。假设GetClientID绝不应该返回NULL或为空。

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

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

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