Перечисление .NET допускает запятую в последнем поле

Question

Почему перечислению .NET разрешено иметь запятую в последнем поле?
Это имеет какое-то особое значение?

[FlagsAttribute]
public enum DependencyPropertyOptions : byte
{
           Default = 1,
           ReadOnly = 2,
           Optional = 4,
           DelegateProperty = 32,
           Metadata = 8,
           NonSerialized = 16,
}

Answer 1

Это не имеет особого значения, просто то, как работает компилятор, в основном по этой причине:

[FlagsAttribute]
public enum DependencyPropertyOptions : byte
{
           Default = 1,
           ReadOnly = 2,
           Optional = 4,
           DelegateProperty = 32,
           Metadata = 8,
           NonSerialized = 16,
           //EnumPropertyIWantToCommentOutEasily = 32
}

По запросу комментария: Эта информация поступает прямо из спецификации C # (Страница 355 / Раздел 17.7)

Как и в стандартном C ++, C # допускает запятую в конце инициализатора массива. Этот синтаксис обеспечивает гибкость при добавлении или удалении членов из такого списка и упрощает машинное создание таких списков.

Answer 2

Также (к сообщению Ника Крэйвера) гораздо проще добавлять новые перечисления.

Это поведение относится не только к перечислениям. Подумайте о следующем:

var list = new int[] { 1, 2, 3, };

Answer 3

Еще одна причина: это облегчает кодирование поколения.

Answer 4

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

Рассмотрим следующий пример:

//version 1
var myArray = {
    "item 1",
    "item 2"
};
//version 2
var myArray = {
    "item 1",
    "item 2", //will be considered a change, it may be considered an erroneous approach
    "item 3"
}

Теперь рассмотрим этот подход:

//version 1
var myArray = {
    "item 1",
    "item 2",
};
//version 2
var myArray = {
    "item 1",
    "item 2", //will not be considered a change, it may be considered an erroneous approach too, but, means that the code wasn't changed intrinsically
    "item 3",
};

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

В любом случае, надеюсь, это поможет.