Code-Review in C#: Was man prüfen sollte und wie man Anfängern Feedback gibt

Code-Review in C#: Wo anfangen und wonach suchen

Code-Review (Code-Überprüfung) ist nicht nur eine Formalität, sondern ein mächtiges Werkzeug zur Verbesserung der Projektqualität und des Teamwachstums. Für Anfänger in C# löst der Prozess der Überprüfung fremden Codes oft Angst aus: "Was, wenn ich einen Bug übersehe?", "Wie sage ich einem Kollegen, dass sein Code schlecht ist?". In diesem Artikel analysieren wir, worauf man bei Code-Reviews in .NET-Projekten achten sollte und wie man Feedback gibt, so dass man gehört wird, ohne zu verletzen.

Wir werden nicht über offensichtliche Dinge wie Syntaxfehler sprechen – diese fängt der Compiler ab. Unser Ziel ist es, Probleme in der Architektur, Lesbarkeit und Leistung zu erkennen sowie Anmerkungen richtig zu formulieren.

1. Architektur und SOLID-Prinzipien in C#

Das Erste, was man in C#-Code prüfen sollte – ob er den SOLID-Prinzipien entspricht. Selbst in einer kleinen Methode kann man eine Verletzung der einzigen Verantwortlichkeit (Single Responsibility) erkennen.

Was prüfen:

• Größe von Methoden und Klassen. Wenn eine Methode länger als 20-30 Zeilen ist, macht sie wahrscheinlich zu viel. Schlagen Sie vor, sie in mehrere private Methoden aufzuteilen.
• Abhängigkeitsinversion. Klassen sollten ihre Abhängigkeiten nicht selbst mit new erstellen. Verwenden Sie stattdessen Dependency Injection (DI). Beispiel für schlechten Code:

// Schlecht: Klasse erstellt Abhängigkeit selbstpublic class OrderService{    private readonly EmailSender _sender = new EmailSender();

    public void ProcessOrder(Order order)    {        // Logik...        _sender.SendEmail(order.CustomerEmail);    }}

Die richtige Variante – über ein Interface und DI:

// Gut: Abhängigkeit wird injiziertpublic class OrderService{    private readonly IEmailSender _sender;

    public OrderService(IEmailSender sender)    {        _sender = sender;    }

    public void ProcessOrder(Order order)    {        // Logik...        _sender.SendEmail(order.CustomerEmail);    }}

• Liskovsches Substitutionsprinzip (LSP). Unterklassen sollten das Verhalten der Basisklasse nicht brechen. Wenn Sie z.B. eine Klasse Bird mit einer Methode Fly() haben und eine Penguin : Bird erstellen, ist das eine LSP-Verletzung, da Pinguine nicht fliegen. Besser ist es, ein Interface IFlyable zu definieren.

2. Fehlerbehandlung und Ausnahmen in .NET

C# hat ein mächtiges Ausnahmesystem, aber Anfänger nutzen es oft falsch. Achten Sie beim Code-Review auf folgende Punkte:

• Leere catch-Blöcke. Code wie catch (Exception) { } ist eine Zeitbombe. Der Fehler wird verschluckt, und Sie erfahren nie vom Problem. Protokollieren Sie die Ausnahme immer oder reichen Sie sie weiter.
• Zu allgemeine Ausnahmen. Das Abfangen von Exception ist eine schlechte Praxis. Versuchen Sie, spezifische Typen abzufangen: SqlException, InvalidOperationException usw.
• Verwendung von Ausnahmen zur Steuerung des Ablaufs. Verwenden Sie try-catch nicht anstelle von if-else. Beispiel für schlechten Code:

// Schlecht: Ausnahme als Teil der Logiktry{    int.Parse(userInput);}catch (FormatException){    Console.WriteLine("Ungültiges Format");}

Die richtige Variante – int.TryParse():

// Gut: Prüfung ohne Ausnahmeif (int.TryParse(userInput, out int result)){    // Arbeiten mit result}else{    Console.WriteLine("Ungültiges Format");}

3. Leistung und Speicherverwaltung

Für Anfänger in C# bleibt das Thema Leistung oft im Hintergrund. Code-Review ist jedoch ein hervorragender Zeitpunkt, um auf ineffiziente Konstrukte hinzuweisen.

Typische Probleme:

• Übermäßige