Reihenfolge der Elemente in den Klassen: Felder, Eigenschaften, Konstrukteure, Methoden

Question

Gibt es eine offizielle C#-Richtlinie für die Reihenfolge der Elemente in Bezug auf die Klassenstruktur?

Funktioniert es:

• Öffentliche Felder
• Private Felder
• Eigenschaften
• Konstrukteure
• Methoden
  ?

Ich bin neugierig, ob es eine feste Regel für die Reihenfolge der Artikel gibt? Ich bin ein bisschen durcheinander. Ich möchte mich an einen bestimmten Standard halten, damit ich es überall machen kann.

Das eigentliche Problem ist, dass meine komplexeren Eigenschaften am Ende sehr wie Methoden aussehen und sich am Anfang vor dem Konstruktor fehl am Platz fühlen.

Irgendwelche Tipps/Vorschläge?

Answer 1

Ich ziehe es vor, die privaten Felder zusammen mit dem/den Konstruktor(en) an den Anfang zu stellen, dann die öffentlichen Schnittstellenbits und dann die privaten Schnittstellenbits.

Wenn Ihre Klassendefinition so lang ist, dass die Reihenfolge der Elemente eine Rolle spielt, ist das wahrscheinlich ein Code-Geruch dass Ihre Klasse zu sperrig und komplex ist und Sie sie umstrukturieren sollten.

Answer 2

Ich halte es so einfach wie möglich (zumindest für mich)

Aufzählungen
Erklärungen
Konstrukteure
Überschreibt
Methoden
Eigenschaften
Ereignis-Handler

Answer 3

Ich weiß, dies ist alt, aber meine Reihenfolge ist wie folgt:

in der Reihenfolge: öffentlich, geschützt, privat, intern, abstrakt

• Konstanten
• Statische Variablen
• Felder
• Veranstaltungen
• Konstrukteur(e)
• Methoden
• Eigenschaften
• Delegierte

Ich schreibe die Eigenschaften auch gerne so aus (anstelle der Kurzschriftmethode)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}

Answer 4

Die einzigen Kodierungsrichtlinien, die ich gesehen habe, vorgeschlagen für diese ist, um Felder an der Spitze der Klassendefinition zu setzen.

Ich neige dazu, Konstrukteure als nächstes einzusetzen.

mein allgemeiner Kommentar würde sein, dass Sie an einer Klasse pro Datei haften sollten und wenn die Klasse groß genug ist, dass die Organisation von Eigenschaften gegenüber Methoden ein großes Anliegen ist, wie groß ist die Klasse und sollten Sie es sowieso refactoring? stellt es mehrere Anliegen dar?

Answer 5

Ich habe die akzeptierte Antwort umstrukturiert, so dass sie meiner Meinung nach besser gestaltet ist:

Innerhalb einer Klasse, Struktur oder Schnittstelle:

• Konstante Felder
• Nur-Lese-Felder
• Felder
• Veranstaltungen
• Eigenschaften
• Indexer
• Konstrukteure
• Finalisten (Zerstörer)
• Schnittstellen (Schnittstellenimplementierungen)
• Methoden
• Klassen
• Strukturen
• Enums
• Delegierte

Innerhalb jeder dieser Gruppen ordnen Sie nach Zugang:

• öffentlich
• intern
• geschützt intern
• geschützt
• privat

Ordnen Sie innerhalb der einzelnen Zugangsgruppen zunächst nach statischen und dann nach nicht-statischen Zugängen:

• statisch
• nicht statisch

Ich bin auch der Meinung, dass verschachtelte Typen auf ein Minimum beschränkt werden sollten. Allzu oft sehe ich Leute, die verschachtelte Klassen, Enums und Delegates haben, die besser eine separate Instanz sein sollten. Die Verschachtelung eines Typs hat fast nie einen Vorteil. Legen Sie sie auch in separate Dateien. Eine Datei mit 5 Klassen wirkt auf mich unübersichtlich.