Если перечисления имеют неинициализированные значения.

Я всегда обнулял один из своих перечислимых литералов. Этот литерал нельзя всегда называть "Ни одним" или "NotSet". Это зависит, если существует литерал, который действует очень хорошо как значение по умолчанию.

Я обнулил тот, потому что, перечисления (кроме nullable перечислений) всегда инициализируются CLR в памяти для обнуления. И если Вы не определяете один из литералов, эта память содержит недопустимые значения. Также, когда Вы используете перечисления в качестве флагов. Значение по умолчанию не может использоваться, чтобы сделать поразрядный compairisons. Результатом всегда будет нуль.

При включении FxCop, он проверяет, определили ли Вы литерал как значение по умолчанию. Кажется, "хорошая практика", когда у них есть правило для этого.

nullable перечисление было предложено как решение в некоторых предыдущих ответах. Но nullable перечисление имеет недостаток, что это осуществляет клиентскую проверку для нулевого значения каждый раз, когда они используют перечисление. Наоборот, если у Вас есть значение по умолчанию "Ни одного", у Вас есть опция использовать переключатель для значимых значений и просто не проигнорировать "Ни один", не имея необходимость волноваться, что перечислимая переменная могла быть пустой.

Так или иначе я думаю, имея значение по умолчанию "Ни одного", или делание nullable перечисления имеет смысл, только если перечисление используется в качестве аргумента в конструкторе по умолчанию для некоторого класса. И необходимо ли спросить себя - не был должен объекты того класса иметь некоторое значимое значение по умолчанию? Используя Ваш пример с перечислением TimeOfDayType - если Вы инициализируете объект с TimeOfDayType. Ни один, Вы не можете использовать его так или иначе перед изменением значения на Утро, День или Вечер. Таким образом, разве Вы не могли сказать, что значение по умолчанию является Утром вместо Ни одного? Или - который еще лучше - разве, Вы не могли создать свои объекты после того, как Вы уже знаете, в каком перечислении значений они нуждаются? Я думаю, что, если с проблемой правильно занимаются в ранних стадиях проектирования, Вам не должно быть нужно специальное значение по умолчанию для Ваших перечислений вообще.

Конечно, все вышеупомянутое является обобщением. Возможно, это не может быть применено к Вашему конкретному сценарию, поэтому если Вы предоставляете некоторую подробную информацию об этом, мы могли бы обсудить вопрос более тщательно.

Зависит, как тип используется. Для пользователей типа часто легче не иметь "неопределенное" значение, потому что у Вас нет к особому случаю одного значения. Но если Вам нужен один (потому что значения иногда должны быть в состоянии, которое иначе не имеет ни одна из перечисляемых ценностей), затем, Вам нужен тот. Вы обычно не сохраняете кода особого случая при помощи двух перечислений вместо одного.

Это немного похоже на выяснение, необходимо ли использовать nullable типы.

Просто добавив к ответу франков, одному из единственных времен я не выбрал бы 'Ни один', который - объект в перечислении по nullable, когда перечисление используется в качестве флагов. 'Ни один' объект не был бы идентификатором 0.

В отсутствие участника "по умолчанию" я думаю, что ценно иметь значение, представляющее литеральный интервал 0.

Независимо от того, что, данное перечисление будет создано с литеральным значением 0. Самый прямой случай здесь как член структуры. Структура C# будет всегда иметь пустого конструктора по умолчанию что initalizes все поля к их значению по умолчанию. В случае перечисления, которое будет литеральным значением 0. Вопрос состоит в том, как обработать его.

Для меня это - проблема стиля: Если перечисление явно не инициализируется к значению, ему нужно дать произвольное допустимое значение или определенное значение, указывающее на отсутствие явной инициализации?

enum Color { Unknown, Red, Blue }
enum Color2 { Red,Blue }
struct Example<T> {
  Color color;
}

static void SomeMethod() {
  var v1 = new Example<Color>();
  var v2 = new Example<Color2>();
}

В случае v1, если поле цвета осмотрено, это будет явно маркировано как неинициализированное поле. В v2 поле будет простой быть "Красным". Нет никакого способа для программиста обнаружить между и явный набор к "Красному" или неявное значение по умолчанию к "Красному".

Другой случай, где это вызывает проблему, делает оператор переключения против перечисления значений. Позволяет немного изменяют определение Color2.

enum Color2 { Red = 1, Blue = 2 }
static void SomeOtherMethod(p1 as Example<Color2>) {
  switch ( p1.color ) {
   case Color.Red: {} 
   case Color.Blue: {}
   default: {throw new Exception("What happened?"); }
  }
}

Переключатель обрабатывает каждое явное значение в перечислении. Все же этот код перестанет работать для конструктора по умолчанию Примера <Color2> и нет никакого способа подавить этого конструктора.

Это поднимает немного более важное правило: Имейте явное перечисление значений для литерального значения 0.