Clean Code in C#: Prinzipien und Beispiele für .NET-Entwickler

Clean Code in C#: Wie man Code schreibt, den man gerne liest

Jeder .NET-Entwickler kennt die Situation, dass der eigene Code nach ein oder zwei Monaten unlesbar wird. Um dies zu vermeiden, gibt es die Philosophie des Clean Code, die von Robert Martin populär gemacht wurde. In diesem Artikel werden wir die wichtigsten Prinzipien von Clean Code in C# mit konkreten Beispielen durchgehen, die Ihnen helfen, wartbare und skalierbare Anwendungen zu schreiben.

Warum ist Clean Code für C#-Entwickler wichtig?

Clean Code ist nicht nur schöne Formatierung. Es ist eine Sammlung von Praktiken, die Code:

• Lesbar machen – jeder Entwickler versteht die Logik schnell;
• Wartbar machen – Änderungen können leicht vorgenommen werden, ohne das System zu gefährden;
• Testbar machen – der Code lässt sich leicht mit Unit-Tests abdecken;
• Effizient machen – keine überflüssigen Abstraktionen oder Redundanzen.

In C# mit seiner strengen Typisierung und den leistungsstarken .NET-Funktionen (LINQ, async/await, Records) ist die Befolgung der Clean-Code-Prinzipien besonders wichtig. Schlechter C#-Code kann zu unerwarteten Fehlern und Performance-Problemen führen.

Prinzip 1: Benennung von Variablen und Methoden

Der Name einer Variable oder Methode sollte die Frage "Was ist das?" oder "Was macht es?" beantworten. Vermeiden Sie einbuchstabige Abkürzungen (außer bei Schleifenindizes).

Schlechtes Beispiel

public class Data{    public int a; // was ist das?    public string b; // unklar

    public void Do(int x, int y) // was macht die Methode?    {        var r = x + y;        Console.WriteLine(r);    }}

Gutes Beispiel (Clean Code)

public class Customer{    public int Id { get; set; }    public string FullName { get; set; }

    public void PrintCustomerSummary(int customerId, int orderCount)    {        var totalOrders = customerId + orderCount;        Console.WriteLine($"Customer {customerId} has {totalOrders} orders");    }}

Regel: Namen sollten aussagekräftig sein. Wenn eine Variable data heißt, ist das fast immer schlecht. Verwenden Sie customerData, orderList, invoiceTotal.

Prinzip 2: Kleine Methoden mit einer einzigen Verantwortung

Jede Methode sollte genau eine Sache tun. Wenn eine Methode mehr als 10-15 Zeilen enthält, sollte sie wahrscheinlich aufgeteilt werden. Dies ist die Grundlage des Single Responsibility-Prinzips (aus SOLID).

Schlechtes Beispiel (Methode macht alles)

public void ProcessOrder(int orderId){    // 1. Validierung    if (orderId <= 0) throw new ArgumentException("Invalid ID");        // 2. Daten aus der DB abrufen    var order = _db.Orders.Find(orderId);        // 3. Rabatt berechnen    decimal discount = 0;    if (order.Total > 1000) discount = order.Total * 0.1m;        // 4. E-Mail senden    var email = new MailMessage();    email.To.Add(order.CustomerEmail);    email.Subject = "Order processed";        // 5. Logging    _logger.LogInformation("Order {Id} processed", orderId);}

Gutes Beispiel (Refactoring)

public void ProcessOrder(int orderId){    ValidateOrderId(orderId);    var order = GetOrderFromDatabase(orderId);    var discount = CalculateDiscount(order);    SendConfirmationEmail(order, discount);    LogOrderProcessing(orderId);}

private void ValidateOrderId(int orderId){    if (orderId <= 0)        throw new ArgumentException("Order ID must be positive", nameof(orderId));}

private Order GetOrderFromDatabase(int orderId){    return _db.Orders.Find(orderId)            ?? throw new InvalidOperationException("Order not found");}

private decimal CalculateDiscount(Order order){    return order.Total > 1000 ? order.Total * 0.1m : 0;}

private void SendConfir
```