C#-Code-Review: 7 Dinge, die Senior-Entwickler nerven

Einleitung: Warum Ihr Code beim Senior einen Tick auslöst

Sie haben einen Pull-Request gesendet. Fünf Minuten vergehen. Im Chat kommt: „Können wir diesen Block hier umschreiben?“ und ein Dutzend Kommentare unter jeder zweiten Zeile. Kommt Ihnen das bekannt vor? Wenn Sie in C# schreiben und im Team arbeiten, ist Code-Review nicht nur ein Häkchen in Jira. Es ist der Moment der Wahrheit.

Ich habe typische Anmerkungen gesammelt, die Seniors bei C#-Code-Reviews hinterlassen. Es geht nicht um Syntax – es geht um Denkweise. Darum, wie man aus „einfach funktionierendem Code“ Code macht, den man nicht gleich am ersten Freitag wieder umschreiben möchte.

Los geht's mit der Analyse der C#-Antipatterns, die selbst die ruhigsten Teamleiter nerven.

1. Magische Zahlen und Zeichenketten: „Was soll das bedeuten?“

Der häufigste Kommentar bei einem C#-Code-Review ist die Frage nach Zahlen. Sie schreiben if (status == 3), und der Senior fragt sofort: „Was ist 3? Ist das der Status 'In Bearbeitung' oder 'Gelöscht'?“.

Schlecht:

if (order.Status == 3 && days > 7)\n{\n    CancelOrder(order);\n}\n

Gut:

private const int OrderStatusCancelled = 3;\nprivate const int MaxDaysBeforeAutoCancel = 7;\n\nif (order.Status == OrderStatusCancelled && days > MaxDaysBeforeAutoCancel)\n{\n    CancelOrder(order);\n}\n

Noch besser ist es, dies in ein Enum auszulagern. Seniors lieben lesbaren Code, bei dem man nicht in die Datenbank schauen muss, um die Geschäftslogik zu verstehen. Das ist eine grundlegende Code-Review-Regel für C#: Der Code sollte für sich selbst sprechen.

2. Async void – der stille Killer von Anwendungen

Wenn Sie async void irgendwo anders als in Event-Handlern (z. B. in WPF oder WinForms) schreiben, machen Sie sich auf eine dicke Minusnote gefasst. Async void kann nicht verfolgt werden – eine Ausnahme fällt ins Nichts und legt den Prozess lahm.

Schlecht:

public async void LoadData()\n{\n    var data = await _repository.GetDataAsync();\n    // Wenn hier ein Fehler auftritt, stürzt die Anwendung ohne Fehlermeldung ab\n}\n

Gut:

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

Bei einem C#-Code-Review wird der Senior Sie garantiert darauf hinweisen. Merken Sie sich: async Task ist Ihr Freund, async void ist Ihr Feind (außer bei Events).

3. Godzilla-Klassen: Single Responsibility Principle

Sie öffnen eine Datei und sie hat 2000 Zeilen. Eine Klasse macht alles: greift auf die Datenbank zu, sendet E-Mails, generiert Berichte und brüht noch Kaffee auf. Das ist ein klassisches C#-Antipattern – das God Object.

Ein Senior wird beim C#-Code-Review sagen: „Lass uns das in mehrere Klassen aufteilen.“ Und er wird recht haben.

Beispiel für einen Verstoß:

public class OrderService\n{\n    public void ProcessOrder(Order order)\n    {\n        // 1. Validierung\n        // 2. Speichern in der DB\n        // 3. E-Mail versenden\n        // 4. Logging\n    }\n}\n

So sollte es sein:

public class OrderProcessor\n{\n    private readonly IOrderValidator _validator;\n    private readonly IOrderRepository _repository;\n    private readonly INotificationService _notificationService;\n\n    public OrderProcessor(\n        IOrderValidator validator,\n        IOrderRepository repository,\n        INotificationService notificationService)\n    {\n        _validator = validator;\n        _repository = repository;\n        _notificationService = notificationService;\n    }\n\n    public async Task ProcessOrderAsync(Order order)\n    {\n        _validator.Validate(order);\n        await _repository.SaveAsync(order);\n        await _notificationService.SendConfirmationAsync(order);\n    }\n}\n

Das ist nicht nur „hübsch“. Es ist testbar. Sie können das Repository mocken und nur die Verarbeitungslogik prüfen. C#-Refactoring in diesem Stil ist ein Must-have für jedes Projekt.

4. Ausnahmen als Kontrollstrukturen