Code review en C# : quoi vérifier et comment donner un retour aux débutants

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Code review en C# : quoi vérifier et comment donner un retour

La code review est l'un des outils les plus puissants pour améliorer la qualité du code. Pour les développeurs C# débutants, cela semble souvent stressant : peur que votre code soit critiqué, ou ne pas savoir quoi chercher dans le code des autres. En réalité, une bonne code review est un dialogue, pas un examen. Dans cet article, nous allons voir sur quoi se concentrer lors de la vérification du code C# (en particulier dans l'écosystème .NET) et comment formuler des remarques qui aident, sans blesser.

\n\n

1. Quoi vérifier dans le code C# : une checklist pour le relecteur

Lorsque vous ouvrez une pull request (PR) d'un collègue, les yeux se perdent. Pour ne pas vous noyer dans les détails, utilisez une approche systématique. Voici les zones clés à vérifier dans tout projet C#.

\n\n

1.1. Architecture et lisibilité

Commencez par évaluer la vue d'ensemble. Répondez aux questions :

Ce code résout-il le problème posé ?
Ne duplique-t-il pas une logique existante (principe DRY) ?
Les noms des classes, méthodes et variables sont-ils clairs ?

Mauvais :

public void DoStuff(int a, int b)\n{\n    var x = a + b;\n    // ... encore 50 lignes\n}

Bon :

public int CalculateTotalPrice(int basePrice, int taxAmount)\n{\n    return basePrice + taxAmount;\n}

Le nom de la méthode et des paramètres indique immédiatement leur objectif. Cela réduit la charge cognitive du lecteur.

\n\n

1.2. Gestion des erreurs et sécurité null

C# est un langage avec un système de types avancé, mais NullReferenceException est un problème fréquent. Vérifiez :

Les vérifications null sont-elles utilisées (?. , ??, ??=) ?
Y a-t-il une gestion des exceptions (try-catch) là où c'est nécessaire ?
Les exceptions ne sont-elles pas avalées dans un catch vide ?

Exemple de code dangereux :

var user = GetUserById(id);\nConsole.WriteLine(user.Name); // Erreur si user == null

Version sécurisée :

var user = GetUserById(id);\nConsole.WriteLine(user?.Name ?? "Invité");

\n\n

1.3. Performance et LINQ

LINQ est pratique, mais peut être inefficace. Vérifiez :

Ne fait-on pas plusieurs passages sur la collection (par exemple, .Where().Select().ToList() sur IQueryable) ?
Any() est-il utilisé à la place de Count() > 0 pour vérifier la présence d'éléments ?
Y a-t-il des matérialisations inutiles (.ToList(), .ToArray()) au milieu d'une chaîne ?

Mauvais :

var list = items.Where(x => x.IsActive).ToList();\nvar first = list.FirstOrDefault();

Mieux :

var first = items.FirstOrDefault(x => x.IsActive);

\n\n

1.4. Async et Task

En .NET, l'asynchrone est la norme. Regardez :

await n'est-il pas oublié devant un appel asynchrone ?
Y a-t-il des appels bloquants (.Result, .Wait()) dans un contexte synchrone ?
La convention est-elle respectée : les méthodes asynchrones se terminent-elles par Async ?

Anti-patron :

var data = GetDataAsync().Result; // Peut provoquer un deadlock

Correct :

var data = await GetDataAsync();

\n\n

2. Comment donner un retour : avec douceur mais de manière constructive

Même la checklist parfaite est inutile si vos commentaires ressemblent à des critiques. Voici quelques règles pour rendre la code review utile pour tous.

\n\n