Clean Code en C# : principes et exemples pour le développeur .NET

Clean Code en C# : comment écrire du code qu'on a envie de lire

Chaque développeur .NET a déjà vécu cette situation où, après un mois ou deux, son propre code devient illisible. Pour éviter cela, il existe la philosophie Clean Code, popularisée par Robert Martin. Dans cet article, nous allons analyser les principes fondamentaux du code propre en C# avec des exemples concrets qui vous aideront à écrire des applications maintenables et évolutives.

Pourquoi Clean Code est-il important pour un développeur C# ?

Le code propre n'est pas qu'un simple formatage esthétique. C'est un ensemble de pratiques qui rendent le code :

• Lisible — tout développeur comprendra rapidement la logique ;
• Maintenable — facile à modifier sans risquer de casser le système ;
• Testable — le code se couvre facilement de tests unitaires ;
• Efficace — absence d'abstractions inutiles et de duplication.

En C# avec son typage fort et les puissantes fonctionnalités de .NET (LINQ, async/await, Records), suivre les principes du Clean Code est particulièrement important. Un mauvais code en C# peut entraîner des bugs non évidents et des problèmes de performance.

Principe 1 : Nommage des variables et des méthodes

Le nom d'une variable ou d'une méthode doit répondre à la question "qu'est-ce que c'est ?" ou "que fait-elle ?". Évitez les abréviations d'une seule lettre (sauf pour les indices de boucles).

Mauvais exemple

public class Data{    public int a; // qu'est-ce que c'est ?    public string b; // pas clair

    public void Do(int x, int y) // que fait la méthode ?    {        var r = x + y;        Console.WriteLine(r);    }}

Bon exemple (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");    }}

Règle : Les noms doivent être expressifs. Si une variable s'appelle data, c'est presque toujours mauvais. Utilisez customerData, orderList, invoiceTotal.

Principe 2 : Petites méthodes avec une seule responsabilité

Chaque méthode doit faire exactement une seule chose. Si une méthode contient plus de 10-15 lignes, il est probable qu'elle doive être divisée. C'est la base du principe Single Responsibility (de SOLID).

Mauvais exemple (la méthode fait tout)

public void ProcessOrder(int orderId){    // 1. Validation    if (orderId <= 0) throw new ArgumentException("Invalid ID");        // 2. Récupération des données depuis la base    var order = _db.Orders.Find(orderId);        // 3. Calcul de la réduction    decimal discount = 0;    if (order.Total > 1000) discount = order.Total * 0.1m;        // 4. Envoi d'email    var email = new MailMessage();    email.To.Add(order.CustomerEmail);    email.Subject = "Order processed";        // 5. Journalisation    _logger.LogInformation("Order {Id} processed", orderId);}

Bon exemple (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