C# im Team: Code Style und Konventionen, die Ihr Projekt retten

Warum Code Style nicht „ich sehe das so“ ist

Haben Sie jemals fremden C#-Code geöffnet und sich wie ein Archäologe gefühlt, der die Ruinen eines antiken Tempels ausgräbt? public int a;, var x = GetSmth() ohne Kontext und Methoden mit 400 Zeilen Länge. Wenn ja – dann wissen Sie, wie sehr ein Team ohne einheitlichen Code Style Kopfschmerzen bekommt.

Teamarbeit bedeutet nicht nur Git und Code Review. Es bedeutet, dass Ihren Code andere Menschen lesen. Und wenn Sie nur für sich selbst schreiben, dann ist Code Style für C# langweilige Bürokratie. Aber wenn Sie für das Team schreiben – ist er die Rettung für Nerven, Zeit und die Produktion.

In diesem Artikel schauen wir uns an, welche C#-Konventionen im Jahr 2024 wirklich funktionieren, wie man sie schmerzfrei einführt und warum EditorConfig Ihr bester Freund ist. Los geht's.

Grundregeln: Worauf man sich zuerst einigen sollte

1. Namensgebung (Naming Conventions)

In C# gibt es strenge Standards, aber Teams verstoßen oft dagegen. Hier ist das goldene Minimum, das 90% der .NET-Teams akzeptieren:

\n
• PascalCase – für Klassen, Methoden, Eigenschaften, öffentliche Felder: public class UserService, public string GetUserName().
\n
• camelCase – für lokale Variablen, Methodenparameter, private Felder (oft mit Präfix _): private int _userId;, var userName = "Alex";.
\n
• Vermeiden Sie die ungarische Notation – strName, intCount – das ist von gestern. Der Variablentyp sollte aus dem Kontext ersichtlich sein.
\n
• Kürzen Sie nicht unnötig – GetUsrInf() ist schlechter als GetUserInformation(). Ausnahme: allgemein übliche Abkürzungen (IO, UI, DTO).
\n

// Schlecht\npublic class user_service\n{\n    public int id;\n    public string nm;\n    private string _data;\n    public string GetData() => _data;\n}\n\n// Gut\npublic class UserService\n{\n    public int Id { get; }\n    public string Name { get; }\n    private readonly string _userData;\n\n    public string GetUserData() => _userData;\n}

2. Formatierung: Leerzeichen, Klammern, Leerzeilen

Die Diskussionen darüber, ob man vor dem Doppelpunkt in catch (Exception e) ein Leerzeichen setzt, sind endlos. Verwenden Sie daher automatische Tools. Aber grundlegende Vereinbarungen sind dennoch nötig:

\n
• Einrückungen – 4 Leerzeichen (Tabulatoren werden in C# selten verwendet, aber wenn das Team sich für Tabs entscheidet, ist das in Ordnung).
\n
• Geschweifte Klammern – immer in einer neuen Zeile (Allman-Stil). Das ist der Standard für C#.
\n
• Eine Leerzeile zwischen Methoden. Zwei zwischen Klassen.
\n

// Schlecht (Klammern in derselben Zeile – das ist Java, nicht C#)\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// Gut (Allman-Stil)\npublic void Process()\n{\n    var result = Calculate();\n    return result;\n}

Fortgeschrittene Konventionen: Woran man am häufigsten scheitert

3. Verwendung von var

Eine der ewigen Diskussionen. Die Regel ist einfach: Verwenden Sie var, wenn der Typ aus der rechten Seite offensichtlich ist. Wenn nicht – schreiben Sie ihn explizit.

// Kann var sein\nvar users = GetUsers(); // Typ ist offensichtlich\nvar dictionary = new Dictionary<string, int>(); // lange Deklaration\n\n// Besser explizit\nUser user = GetUserById(id); // nicht offensichtlich, dass User zurückgegeben wird\nDictionary<string, int> result = ParseData(); // ebenfalls nicht offensichtlich

Wenn Ihr Team var nicht mag – einigen Sie sich einfach. Hauptsache Einheitlichkeit.

4. Arbeiten mit LINQ

LINQ ist ein mächtiges, aber tückisches Werkzeug. Ein häufiger Fehler sind Ketten von 10 Methoden, die sich wie ein Zauberspruch lesen. Einigen Sie sich:

\n
• Teilen Sie lange LINQ-Ausdrücke auf mehrere Zeilen auf.
\n
• Verwenden Sie .Select() nicht übermäßig, wo ein pr