C# Coding Guidelines @Microsoft

Ich werde oft über die Coding Guidelines bei Microsoft befragt. Mh, eigentlich sind die Recht überschaubar wenn es um die reinen Coding Guidelines geht. Hier mal ein Paar Fragen an die ich mich erinnnern kann:

  • Verwendet ihr eigentlich this.?
  • Wie benennt Ihr Variablen? strName für Variable vom Typ String mit dem Bezeichner Name?
  • Welche Typen verwendet Ihr?
  • Benutzt Ihr FXCop?

Also dachte ich mir, ich erzähle mal ein bischen was über unsere Coding Guidelines. Also im Prinzip kann man sagen, wir verwenden die Default Visual Studio Settings. Ich kann auch keine Aussage über die OSG also Windows Jungs machen, vielleicht frage ich mal Jürgen und Martin wie die das machen? Insgesamt haben wir hier ein Paar Herausforderungen. Da unterschiedliche Teams oft Unterschiedliche Guidelines verwenden. Die folgenden 12 Regeln beschreiben die C# Guidelines.

1. Allman style rockt!

Mal ganz Allgemein wir verwenden "Allman Style" Klammern. Das bedeutet das jede Klammer in einer Neuen Zeile beginnt und unter dem Control Statement steht. Man referenziert das auch als "BSD style" da Allman viele Tools für BSD Unix geschrieben hat. Auch wenn in BSD selbst der KNF Style verwendet wurde. Was ich persönlich super lustig finde.

Hier ein Beispiel für Allmann style:

Okay da kommen wir dann auch schon zum if-Statement. Hier haben wir uns auf folgendes geeinigt. (Issue: #381)

Hier gibt es ja drei Möglichkeiten:

  • Niemals den Single-Line Style verwenden. ( Was kann den schon schief gehen? :) )
  • Ohne Klammern
    • Nur dann erlaubt wenn jeder Codeblock der mit einem if / else /else if / ... Statement aus genau einer Zeile besteht.
  • Mit Klammern
    • Immer erlaubt
    • Wenn einer der Code-Blöcke in einem if / else if / ... / else Statement Klammern verwendt, müssen alle Blöcke des Statements Klammern verwenden.
    • Wenn eine Anweisung oder Statement über mehrere Zeilen geht oder die Anweisung gesplited wird damit Sie leichter lesbar ist, müssen Klammern verwendet werden.

2. Tabulator oder nicht Tabulator?

Die Antwort ist kurz! Wir verwenden hier 4 Leerzeichen und keine Tabulator Einrückung!
Ja, ich weiß, ich weiß ... =).

3. CamelCase und Prefixes bei Members?

Wir verwenden bei internal und private Members _camelCase. Wann immer Möglich verwenden wir readonly!

Verwendete Prefixes:

  • Instance field: _
  • Static fields: s_
  • Thread static fields: t_

4. "this." ist das gut für mich?

Nein, this. ist zu vermeiden wann immer möglich.

5. Sichtbarkeit auch Sichtbar?

Wir geben die Sichtbarkeit immer an, auch dann wenn es die Standard Sichtbarkeit ist.
private sting _foo nicht string _foo.

6. Namespace und Usings

Imports sollten immer ganz oben in der Datei definiert werden und oberhalb des Namespaces stehen. (Ja, FXCop sagt hier was anderes.) Usings sollten alphabetisch sortiert sein. Man beginnt immer mit den System.* Namespaces und Leerzeilen zwischen unterschiedlichen "top level" Gruppen.

7. Leerzeilen soviel ich will?

Es gilt die Regel nie mehr als eine Leerzeile zu verwenden. Auch oder gerade bei der Initialisierung von Members.

8. Leerzeichen soviel ich will?

Keine stöhrenden Leerzeichen verwenden. Zum Beispiel: if (someVar == 0)... In diesem Fall symbolisieren die drei Punkte stöhrende Leerzeichen. Wir verwenden das "View White Space (Ctrl+E,S)" Feature in Visual Studio um den Überblick zu behalten.

Für die Regeln 7 und 8 gibt es derzeit keinen Tooling Support von Visual Studio.

9. Was wenn in der Datei ein anderer Style verwendet wird?

Wenn es eine Datei gibt die einen anderen Style verwendet, hat dieser Style Vorrang. Bsp.: Ein privates Feld hat den Namen m_member anstelle von _member dann gilt die Konvention m_member für alle weiteren Felder die in dieser Datei hinzugefügt werden. Also ist die Ausnahme höher priorisiert als die Regel. Warum? Interop, Interop, Interop. =)

10. Ducktyping vs. Typeinfo

Wir verwenden das Keyword var nur dann, wenn es absolut klar ist, was der Variablen Typ ist.
var stream = new FileStream(); nicht var stream = OpenStandardInput();

11. Keywords vs. BCL types?

Wir verwenden die Language Keywords anstelle der BCL types.
int, string, float anstatt Int32, String, Singel ... Das gilt sowohl für Referenzen als auch für Methoden Aufrufe.
int.Parse anstatt Int32.Parse.

Die Diskussion zu diesem Thema findet Ihr unter: Language or BCL data types #391

12. PascalCasing

Wir verwenden PascalCasing um geeignete Bezeichner für Konstanten und lokale Variablen und Felder zu definieren. Ausnahme ist Interop Code in dem der Konstantenwert exakt dem Konstantenwert des aufgerufenen Interop-Codes sein muss.

Beispiel

Als Beispiel für die C# Coding Guidlines @Microsoft hier dieObservableLinkedList<T> Klasse:

Guidelines als Visual Studio Settings

Das .net Team hat seine Visual Studio 2013 vssettings Veröffentlicht in dem mit Ausnahme von Regel 7 und 8 alle Konventionen berücksichtigt sind. Hier der Link zur corefx.vssettings Datei.

Guidelines als Tool

Ausserdem haben wir ein Tool veröffentlicht, das mit Visual Studio 2015 funktioniert und die Microsoft .net Compiler Platform aka Roslyn verwendet um bestehenden SourceCode umzuschreiben, so dass er sich an die Guidelines hält. Das codeformatter Tool steht Open Source auf GitHub zur Verfügung. Hier besteht allerdings eine Abhängigkeit zu den Microsoft Build Tools 2015, die auf der lokalen Maschine installiert sein müssen. Man findet die MS Build Tools in der MSDN Subscription oder als seperater Download auf der Visual Studio Seite unter Additional Tools - Microsoft Build Tools 2015.

Das wars schon?

Ja, so ziemlich - na ja, also jetzt kommen mehr oder weniger die Framework Design Guidelines ins Spiel. Auf Github findet Ihr eine Zusammenfassung der Guidelines. Dort findet man auch weitere Resourcen wie bspw.: TechEd 2007 Präsentation zu diesem Thema. Wenn ich mich richtig erinnere hatten wir hier früher zwei Tools im Einsatz: FXCop StyleCop und ein zweites internes Tool. Und das wars dann auch schon Tatsächlich.

In diesem Sinne Happy Coding mit den Microsoft Guidelines. =)

Ergänzung:
Das .net Framework Team hat eine offene Diskussion zu diesem Thema.