Code propre en C# : comment écrire pour ne pas avoir honte de le montrer à ses collègues

Introduction : pourquoi le code propre n'est pas une question d'esthétique, mais d'argent

Imaginez que vous arrivez dans un nouveau travail, que vous ouvrez un projet en C# et que vous voyez une méthode de 500 lignes, des variables a, b, temp, et des commentaires écrits dans un mélange de russe et d'anglais. Cela vous dit quelque chose ? Probablement, oui. Un tel code fonctionne, mais sa maintenance devient un enfer. Le code propre en C# n'est pas un caprice de perfectionniste, mais un outil qui économise des heures, des nerfs et de l'argent à l'équipe.

Dans cet article, nous ne ferons pas la morale. Au lieu de cela, nous analyserons des techniques concrètes qui vous aideront à écrire en C# de manière à ce que le code soit compréhensible pour un débutant et ravisse un développeur expérimenté. C'est parti !

1. Les noms ont de l'importance : comment nommer les variables, les méthodes et les classes

Le moyen le plus simple de rendre le code plus propre est de donner des noms significatifs. C# est sensible à la casse, mais ce n'est pas une excuse pour int x ou string d.

Variables : dites ce que vous stockez

Mauvais :

int d; // qu'est-ce que c'est ? date ? distance ? argent ?string n; // nom ? numéro ? ordinateur portable ?

Bon :

int daysUntilDeadline;string userName;

La règle est simple : si dans un mois vous ne pouvez pas comprendre ce que stocke une variable sans commentaire, le nom est mauvais. Évitez les abréviations comme usr ou cnt — elles économisent une seconde à la saisie, mais prennent des minutes à la lecture.

Méthodes : verbe + nom

Une méthode est une action. Nommez-la de manière à ce qu'il soit clair ce qu'elle fait :

• CalculateTotalPrice() — calcule le prix total ;
• SendEmailNotification() — envoie une notification ;
• ValidateUserInput() — valide la saisie de l'utilisateur.

Mauvais exemple : ProcessData() — trop abstrait. Que signifie "traiter" ? Supprimer ? Transformer ? Sauvegarder ?

Classes : noms au singulier ou au pluriel

Une classe est une entité. User, Order, PaymentProcessor. Évitez les suffixes comme Manager ou Helper, sauf si cela est justifié par l'architecture. Souvent, ces classes deviennent un "dépotoir" pour tout et n'importe quoi.

2. Les méthodes doivent être petites et faire une seule chose

La règle d'or du code propre : une méthode doit résoudre une seule tâche et bien la résoudre. Si une méthode fait plus de 20 à 30 lignes, il est probable qu'elle doive être divisée.

Exemple : refactoring d'un monstre

Imaginez une méthode qui enregistre un utilisateur :

public void RegisterUser(string name, string email){    // validation    if (string.IsNullOrWhiteSpace(name)) throw new ArgumentException();    if (!email.Contains("@")) throw new ArgumentException();    // sauvegarde en BDD    using var db = new AppDbContext();    var user = new User { Name = name, Email = email };    db.Users.Add(user);    db.SaveChanges();    // envoi d'email    var smtp = new SmtpClient();    smtp.Send("admin@site.com", email, "Welcome", "Hello!");}

Qu'est-ce qui ne va pas ici ? Trois responsabilités : validation, travail avec la BDD, envoi d'email. Si la logique d'envoi change, il faudra toucher à la méthode d'enregistrement. Divisons :

public void RegisterUser(string name, string email){    ValidateUser(name, email);    var user = CreateUser(name, email);    SaveUser(user);    SendWelcomeEmail(email);}

private void ValidateUser(string name, string email){    if (string.IsNullOrWhiteSpace(name))         throw new ArgumentException("Name is required", nameof(name));    if (!email.Contains("@"))         throw new ArgumentException("Invalid email", nameof(email));}

private User CreateUser(string name, string email){    return new User { Name = name, Email = email };}

private void SaveUser(User user){    using var db = new AppDbContext();    db.Users.Add(user);    db.SaveCh