C# Code Review: Prüfpunkte für sauberen Code

C# Code Review: Mehr als nur ein Häkchen – der Schutz für deine Produktion

Kennst du das? Code, der zwar funktioniert, bei dem man aber am liebsten die Augen schließen möchte? „Magische Zahlen“, verschachtelte Schleifen, async void und null an Stellen, wo es nichts zu suchen hat. Ein C# Code Review ist keine lästige Bürokratie, sondern die letzte Verteidigungslinie, bevor ein Bug in die Produktion gelangt. Oder, noch schlimmer, bevor deine Kollegen den Code warten müssen und den Autor verfluchen.

In diesem Artikel schauen wir uns an, worauf du bei einem C# Code Review wirklich achten musst. Kein Blabla – nur konkrete Fälle, Antipatterns und Beispiele. Bist du ein Junior? Dann ist dies deine Checkliste. Bist du ein Senior? Dann frisch dein Wissen auf. Los geht's.

1. Null – der Erzfeind eines jeden C#-Entwicklers

Die berüchtigte NullReferenceException ist der Grund für Millionen schlafloser Nächte. Das Erste, was wir im Code Review prüfen: der Schutz vor null.

Worauf solltest du achten?

\n
• Fehlende Null-Prüfung vor dem Zugriff auf Eigenschaften.
\n
• Rückgabe von null aus Methoden, bei denen eine Collection erwartet wird.
\n
• Ignorieren von nullable-Kontexten (#nullable enable).
\n

Schlecht:

public string GetUserName(User user)\n{\n    return user.Name.ToUpper(); // user könnte null sein!

Gut (C# 8+):

public string GetUserName(User? user)\n{\n    return user?.Name?.ToUpper() ?? "Unbekannt";\n}

Tipp fürs Code Review: Bestehe auf der Aktivierung von Nullable in neuen Projekten. Das ist nicht nur modern, sondern schützt vor dummen Fehlern. Ein C# Code Review ohne Nullable-Prüfung ist wie Autofahren ohne Sicherheitsgurt.

2. Asynchronität: async/await ohne Fallstricke

Asynchrone Programmierung in C# ist ein mächtiges Werkzeug, aber bei falscher Anwendung wird es zur Zeitbombe. Im Review prüfen wir drei Hauptsünden.

Sünde Nr. 1: async void

async void-Methoden können nicht verfolgt werden – eine Exception fällt in den finalen Thread und killt den Prozess. Nur für Event-Handler erlaubt (z. B. Button-Klick in WinForms).

Schlecht:

public async void LoadDataAsync()\n{\n    var data = await _service.GetDataAsync(); // Ein Fehler killt den Prozess\n}

Gut:

public async Task LoadDataAsync()\n{\n    var data = await _service.GetDataAsync();\n}

Sünde Nr. 2: Blockieren von asynchronem Code

.Result oder .Wait() in einem asynchronen Kontext ist der sichere Weg zu einem Deadlock.

Schlecht:

var result = _service.GetDataAsync().Result; // Deadlock in UI-Apps

Gut:

var result = await _service.GetDataAsync();

Sünde Nr. 3: Fehlender CancellationToken

Langlaufende Operationen sollten abbrechbar sein. Fehlt CancellationToken in der Methodensignatur, frage den Autor: „Was passiert, wenn der Benutzer den Tab schließt?“

3. LINQ: Schönheit oder langsamer Tod?

LINQ ist elegant. Aber ein Code Review zeigt oft, dass hinter der Eleganz O(n²) oder mehrfache Collection-Durchläufe stecken.

Typische Fehler im C# Code Review mit LINQ:

\n
• Mehrfacher Durchlauf: .Count() > 0 + .First() – zwei Durchläufe. Nutze .Any() und .FirstOrDefault().
\n
• Vergessenes ToList(): Lazy Loading kann dazu führen, dass die DB-Abfrage ausgeführt wird, nachdem der DataReader-Kontext bereits geschlossen ist.
\n
• Where + Select = Redundanz: Wenn ein einzelnes SelectMany ausreicht, nutze es.
\n

Ein Beispiel, das alle Alarmglocken schrillen lassen sollte:

var result = l