.NET-Enumeration ermöglicht Komma im letzten Feld

Question

Warum ist diese .NET-Enumeration zulässig, ein Komma im letzten Feld zu haben?
Hat das eine besondere Bedeutung?

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

Answer 1

Es keine besondere Bedeutung hat, sondern nur die Art und Weise der Compiler funktioniert, es ist vor allem aus diesem Grund:

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

Kommentar Anfrage: Diese Information kommt direkt aus dem C# Specification (Page 355/Section 17.7)

Wie Standard C++ erlaubt C# ein abschließendes Komma am Ende eines Array-Initialisierers. Diese Syntax bietet Flexibilität beim Hinzufügen oder Löschen von Elementen aus einer solchen Liste und vereinfacht die maschinelle Erstellung solcher Listen.

Answer 2

Auch (zu Nick Craver Post) ist es viel einfacher, neue Aufzählungen hinzuzufügen.

Dieses Verhalten eignet sich nicht nur für enums. Folgendes beachten:

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

Answer 3

Ein anderer Grund: Es macht es einfacher, gen zu codieren.

Answer 4

Ich weiß, das ist ein altes Thema, aber ein anderer Ansatz, der für dieses Problem sinnvoll ist, ist für Code-Versionssysteme.

Betrachten Sie das folgende Beispiel:

//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" 
} 

nun diesen Ansatz betrachten:

//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", 
}; 

Wie auch immer, kann beiden Ansätze falsch oder richtig in Abhängigkeit von der Situation in Betracht gezogen werden. Ich bevorzuge besonders den zweiten Ansatz, der im Umgang mit Code-Versionssystemen viel sinnvoller ist.

Auf jeden Fall hoffe das hilft.