Clean Code en C# : principes et exemples pour débutants

Clean Code en C# : Le chemin vers un code professionnel

Chaque développeur rêve d'écrire un code qui non seulement fonctionne, mais qui est aussi facile à lire, à maintenir et à étendre. Le concept de "code propre" (Clean Code), popularisé par Robert Martin, n'est pas simplement un ensemble de règles, mais une philosophie de professionnalisme. Dans cet article, nous allons analyser les principes clés du Clean Code appliqués au langage C# et à la plateforme .NET, en utilisant des exemples simples et compréhensibles pour les débutants. Vous apprendrez comment transformer un code "sale" en une solution élégante et fiable.

1. Des noms explicites : Le premier pas vers la propreté

La partie la plus importante du code propre est le nommage. Le nom d'une variable, d'une méthode, d'une classe ou d'une interface doit répondre aux questions "Qu'est-ce que c'est ?" ou "Que fait-elle ?". De bons noms évitent d'avoir à écrire des commentaires.

Exemples mauvais et bons

Évitez les abréviations d'une seule lettre (sauf pour les compteurs de boucles) et les noms abstraits.

// MAUVAIS : Noms peu clairs\nint d; // elapsed time in days\nList<string> l = new List<string>();\n\npublic void Proc(int x) \n{\n    // ...\n}\n\n// BON : Noms explicites\nint elapsedTimeInDays;\nList<string> customerNames = new List<string>();\n\npublic void ProcessOrder(int orderId)\n{\n    // ...\n}

Règles pour C# :

\n
• Classes et méthodes — PascalCase (par exemple, OrderService, CalculateTotal).
\n
• Variables locales et paramètres — camelCase (par exemple, orderId, customerName).
\n
• Interfaces — commencent par la lettre I (par exemple, IRepository).
\n
• Évitez la "notation hongroise" (comme strName). Le type de la variable doit être évident d'après le contexte.
\n

2. Fonctions : Petites et ne faisant qu'une seule chose

Une fonction (ou méthode) doit être petite et n'effectuer qu'une seule tâche (Single Responsibility Principle au niveau des méthodes). Si une fonction fait plusieurs choses, elle doit être divisée en fonctions plus petites.

Refactoring d'une grande fonction

Imaginez que nous devons enregistrer une commande et envoyer une notification. Un mauvais code fait tout à la fois.

// MAUVAIS : La fonction fait trop de choses\npublic void SaveOrderAndNotify(Order order)\n{\n    // 1. Validation\n    if (order.Items.Count == 0) throw new Exception("Empty order");\n\n    // 2. Sauvegarde en BDD (hypothétique)\n    Console.WriteLine($"Order {order.Id} saved.");\n\n    // 3. Envoi d'email\n    Console.WriteLine($"Notification sent to {order.CustomerEmail}.");\n}\n\n// BON : Division en petites fonctions\npublic void ProcessOrder(Order order)\n{\n    ValidateOrder(order);\n    SaveOrder(order);\n    SendOrderConfirmation(order);\n}\n\nprivate void ValidateOrder(Order order)\n{\n    if (order.Items.Count == 0)\n        throw new InvalidOperationException("Cannot process an empty order.");\n}\n\nprivate void SaveOrder(Order order)\n{\n    // Logique de sauvegarde\n    Console.WriteLine($"Order {order.Id} saved.");\n}\n\nprivate void SendOrderConfirmation(Order order)\n{\n    // Logique d'envoi\n    Console.WriteLine($"Notification sent to {order.CustomerEmail}.");\n}

Conseil : Essayez de garder le même niveau d'abstraction à l'intérieur d'une seule fonction. Ne mélangez pas le travail avec la base de données et le formatage du texte dans une même méthode.

3. Gestion des erreurs et des exceptions

Le code propre gère les erreurs de manière prévisible. En C#, on utilise pour cela les exceptions. Évitez de retourner des "nombres magiques" (par exemple, -1) ou null pour indiquer une erreur.

// MAUVAIS : Retour de null en cas d'erreur\npublic User FindUser(int id)\n{\n    if (id <= 0) return null; // Que doit faire le code appelant ?\n    // ... recherche\n    return n