Comment écrire un code lisible et maintenable?

Introduction

Tu passes des heures devant ton écran, à écrire du C#, à construire des fonctionnalités, à résoudre des bugs.

Et pourtant…

Tu reviens sur un bout de code que tu as écrit il y a trois semaines, et tu te demandes :

“Mais… qu’est-ce que j’ai voulu faire ici ?”

Tu n’es pas seul.

Et ce n’est pas parce que tu es mauvais.

C’est juste que personne ne t’a appris à écrire du code lisible.

On t’a appris à faire fonctionner les choses.

Mais pas à les rendre maintenables, évolutives… et humaines.

Dans cet article, je veux t’aider à passer d’un développeur qui “écrit du code” à un développeur qui construit un héritage durable.

Pas de jargon pompeux.

Juste des conseils concrets, comme si on discutait autour d’un café.

Et surtout : des idées que tu pourras appliquer dès demain — même si tu débutes.

Tout le monde peut écrire du code que la machine comprend. Un bon développeur écrit du code que les humains comprennent.”
— Adapté de Martin Fowler

Pourquoi la lisibilité, c’est ta nouvelle superpuissance ?

Imaginons deux équipes :

Équipe A : code rapide, fonctionnel, mais obscur. Chaque changement prend des jours. Les nouveaux arrivants sont perdus.
Équipe B : code lent à écrire… mais ultra-clair. Les évolutions sont rapides. Les nouveaux collaborent dès le jour 1.

Devine laquelle coûte moins cher à long terme ?

👉 Spoiler : c’est l’équipe B.

Selon Microsoft, jusqu’à 80 % du temps de développement est passé à lire du code, pas à en écrire.

Donc, si ton code est difficile à lire, tu perds du temps.

Toi.

Tes collègues.

Ta boîte.

La vraie productivité, ce n’est pas d’écrire vite. C’est de comprendre vite.

1. Des noms qui parlent, pas des énigmes

Ferme les yeux.

Lis ce nom de variable : empAge.

Tu comprends ?

Oui, mais tu dois réfléchir.

Et chaque micro-pause, c’est de l’énergie mentale perdue.

Et si tu lisais employeeAge ?

Immédiat.

Clair.

Sans effort.

Voici les règles simples du .NET (selon Microsoft, mais adaptées à la vraie vie) :

Pour les classes, méthodes et propriétés, utilise le PascalCase. Par exemple : CustomerService, GetOrder(), FirstName. La première lettre de chaque mot est en majuscule.
Pour les variables locales et les paramètres de méthode, préfère le camelCase.Comme dans : customerName, orderCount. Ici, seul le premier mot commence en minuscule, les suivants prennent une majuscule.
Les interfaces doivent toujours commencer par un I majuscule, suivi du PascalCase.Exemple : IOrderRepository, IUserService. Ce petit I en début de nom, c’est comme un panneau indicateur : “attention, c’est une interface !”
Enfin, pour les constantes, on utilise tout en majuscules avec des underscores : UPPER_CASE.Par exemple : MAX_LOGIN_ATTEMPTS, DEFAULT_TIMEOUT.

Cela permet de les repérer instantanément dans le code.

Astuce humaine :

Imagine que tu lis ton code à voix haute à un stagiaire.
Si tu dois expliquer, c’est que le nom n’est pas assez clair.

Et surtout : sois cohérent.

Mieux vaut une convention moyenne partout qu’une convention parfaite… mais inégale.

🔧 Outil malin : Installe StyleCop.Analyzers dans ton projet. Il te rappelle gentiment quand tu oublies une règle. Comme un petit coach dans ton IDE.

2. Découpe comme un chef : petites méthodes, gros impact

Un plat de pâtes, c’est simple.

Mais si le chef fait tout en même temps — cuire, assaisonner, servir, nettoyer — c’est le chaos.

En code, c’est pareil.

Une méthode de 100 lignes qui fait tout ?

👉 C’est une bombe à retardement.

Voici la règle d’or :

Une méthode = une seule chose.

Exemple :

public void GenerateInvoice(Customer customer)
{
    var invoice = CreateInvoice(customer);
    SaveInvoice(invoice);
    SendInvoiceEmail(invoice);
}

Trois lignes. Trois responsabilités.

Et chaque méthode peut être testée indépendamment.

Dialogue imaginaire :

– “Mais ça fait plus de lignes !”

– Oui. Et c’est mieux.

Parce que maintenant, tu peux dire : “Crée une facture. Sauvegarde-la. Envoie-la.”

C’est du code qui parle.

Et pour les listes ?

Utilise LINQ.

C’est comme un filtre à pensée claire :

var adults = customers.Where(c =&gt; c.Age &gt;= 18).OrderBy(c =&gt; c.Name);

3. Architecture propre : ton code a besoin d’un plan

Tu ne construis pas une maison sans plan.

Alors pourquoi le faire avec ton code ?

En .NET, deux architectures s’imposent :

Layered Architecture (couche par couche) : Présentation → Application → Domaine → Infrastructure.
Clean Architecture : le domaine au centre, tout le reste autour.

Métaphore :

Ton domaine, c’est le cœur.

L’infrastructure (base de données, API), c’est la peau.

Si tu changes la peau, le cœur ne doit pas mourir.

Et pour relier tout ça ?

L’injection de dépendances.

C’est comme un restaurant où chaque service (cuisine, service, caisse) travaille ensemble… sans se coller.

services.AddScoped&lt;IOrderService, OrderService&gt;();

Et en .NET 9 ?

Profite des record pour des objets immuables :

public record Customer(string Name, int Age);

Plus de risque de modifier par erreur.

✅ Code plus sûr.

✅ Plus lisible.

4. Commenter ? Oui, mais seulement quand c’est utile

Le meilleur commentaire ?

Celui qui n’existe pas.

Parce que le code parle de lui-même.

Mais parfois, il faut expliquer le pourquoi, pas le quoi.

❌ Mauvais :

// Vérifie si l'email est valide
if (email.IsValid()) ...

👉 Le code dit déjà ça.

✅ Bon :

// On envoie le mail uniquement si l'adresse est validée par l'utilisateur (RGPD)
if (customer.EmailConfirmed) ...

✨ Là, tu expliques le contexte métier.

C’est ça, la vraie valeur d’un commentaire.

Et pour la doc ?

Utilise les XML Comments (///) + Swagger.

Tu génères une documentation automatique.

Tes collègues (et toi dans 6 mois) te remercieront.

5. Tes outils secrets pour du code propre

Tu n’es pas seul.

L’écosystème .NET est blindé d’outils pour t’aider.

Voici ton kit de survie :

Roslyn Analyzers : détectent les mauvaises pratiques en temps réel.
SonarLint : ton coach de code dans Visual Studio.
xUnit / NUnit : pour des tests unitaires solides.
GitHub Actions / Azure DevOps : lance des tests et du linting à chaque commit.

🎯 Astuce pro :

Configure un pipeline CI/CD qui bloque les pull requests si le code ne respecte pas les règles.

Comme un filet de sécurité.

Et les revues de code ?

C’est ton super-pouvoir d’apprentissage.

Chaque PR est une mini-formation.

💬 “Ton code est un peu long ici, tu pourrais le découper ?”

→ Ce n’est pas une critique. C’est de l’aide.

6. Gérer les erreurs… sans les cacher

Un try-catch vide, c’est comme un incendie qu’on ignore.

❌ À bannir :

try { ... }
catch (Exception) { }

👉 Tu perds l’erreur. Et le bug reviendra, plus fort.

✅ Fais plutôt :

try
{
service.ProcessOrder(order);
}
catch (PaymentException ex)
{
logger.LogError(ex, "Erreur de paiement pour la commande {OrderId}", order.Id);
throw; // Réémet l'erreur si tu ne peux pas la gérer
}

🔍 Règle simple :

Attrape seulement les exceptions que tu peux gérer.

Sinon, laisse-les remonter.

Et logge-les toujours.

🔄 7. Avant / Après : la transformation magique

Voici un code “avant” typique :

public void DoIt(Customer c)
{
if (c.Age >= 18)
{
if (c.HasValidLicense)
{
Database.Save(c);
}
}
}

👉 Fonctionne.

👉 Mais illisible.

👉 Et impossible de tester.

Et maintenant, le “après” :

public void RegisterCustomer(Customer customer)
{
if (!IsEligible(customer)) return;
SaveCustomer(customer);
}

private bool IsEligible(Customer customer)
=> customer.Age >= 18 && customer.HasValidLicense;

private void SaveCustomer(Customer customer)
{
// Logique de sauvegarde
}

✅ Lisibilité.

✅ Testabilité.

✅ Maintenabilité.

Un petit changement. Un gros impact.

Et après ? Continue à grandir

Voici mes conseils d’humain à humain :

Écris ton code comme un livre : chaque classe, chaque méthode, devrait raconter une histoire.
Refactore petit à petit : tu n’as pas à tout changer aujourd’hui. Une méthode à la fois.
Explore les projets open source : regarde comment ASP.NET Core est structuré. C’est une mine d’or.
Évite les “magic numbers” : const int MIN_AGE = 18; > 18.
Utilise les nouveautés de C# : List<int> numbers = [1, 2, 3]; — plus clair, non ?

Conclusion : Écrire du code propre, c’est un acte de bienveillance

Écrire du code lisible, ce n’est pas juste une question de technique.

C’est un acte de respect :

Envers toi-même (dans 6 mois).
Envers tes collègues.
Envers les futurs développeurs qui reprendront ton projet.

🌱 Tu n’apprends pas à écrire du code propre en un jour.

Mais chaque petite amélioration compte.

Alors commence maintenant.

Prends une méthode.

Donne-lui un meilleur nom.

Découpe-la.

Et souris en sachant que tu viens de rendre le monde… un peu plus lisible.

🗣️ Et toi ?

Quelle est ta pratique préférée pour garder un code propre en .NET ?

Partage en commentaire — ou envoie-moi un message.

J’adore ces échanges.

Parce qu’on apprend mieux… ensemble.