可以为空的枚举或其他元素

Question

考虑以下枚举和该类型的相应可空字段

enum PossibleOptions { One, Two }

PossibleOptions? option;

或者我可以将枚举和相应的字段声明为

enum PossibleOptions { Unspecified, One, Two }

PossibleOptions option;

这个不可为空的字段将被初始化为第一个值，即'Unspecified'，并且我实现了与nullable相同的结果（'Unspecified'将替换option.HasValue）。

为什么选择Nullable呢？任何性能提升或其他优势？

Answer 1

我知道你在询问有关可以为空的枚举的理由，但我个人认为没有理由使用它们。

具有“无效”成员的枚举在我看来更具可读性，并且传达的意义远远超过可以为空的。

Answer 2

根据documentation：

  

默认的基础类型   枚举元素是int。通过   默认情况下，第一个枚举器具有   值0，以及每个值   连续的普查员增加了   1。

     

...

     

枚举E的默认值是   由表达式（E）0产生的值。

还可以修改此默认值：

enum PossibleOptions { Unspecified = 1, One, Two }

在这种情况下，Unspecified将不再是默认值。

我可以看到使用可空枚举的唯一可能优点是null值不依赖于枚举的定义。

在我看来，您应根据是否需要默认值或未分配值的语义来决定使用哪一个。

Answer 3

我会选择枚举的额外“未指定”值。使用可空值，您可以假设另一个开发人员会传递null。使用完整的值数组，没有任何假设 - 在该值集中，每个可能的选项都是明确的。

Answer 4

除了已经说过的内容之外，我认为性能明智的可空枚举也更糟糕，因为它们会导致更多的内存分配。

看似无辜的代码如下：

doSomething(PossibleOptions.One);
doSomething(null);

private void doSomething(PossibleOptions? option)
{
    ...
}

实际上编译成这样的东西：

doSomething(new PossibleOptions?(PossibleOptions.One));
doSomething(new PossibleOptions?());

对于所有的nulbles来说都是如此，但我发现它对于枚举尤其令人惊讶（对于布尔运算更是如此），因为我的第一个本能是认为这将由编译器优化，因为它事先知道所有可能的值并且可以缓存和使用它们。

Answer 5

使用可以为空的枚举的唯一原因（除个人偏好外）是你使用和不使用可以为空的。

通过使用可为空的枚举，您没有将null值作为其中一个值。您可以从可空属性中获取值，并将其用于其中null值不应该是可能值的其他位置。