Code review en C# : quoi vérifier et comment donner un retour
\nLa 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\n1. Quoi vérifier dans le code C# : une checklist pour le relecteur
\nLorsque 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\n1.1. Architecture et lisibilité
\nCommencez par évaluer la vue d'ensemble. Répondez aux questions :
\n- \n
- Ce code résout-il le problème posé ? \n
- Ne duplique-t-il pas une logique existante (principe DRY) ? \n
- Les noms des classes, méthodes et variables sont-ils clairs ? \n
Mauvais :
\npublic void DoStuff(int a, int b)\n{\n var x = a + b;\n // ... encore 50 lignes\n}\nBon :
\npublic int CalculateTotalPrice(int basePrice, int taxAmount)\n{\n return basePrice + taxAmount;\n}\nLe nom de la méthode et des paramètres indique immédiatement leur objectif. Cela réduit la charge cognitive du lecteur.
\n\n1.2. Gestion des erreurs et sécurité null
\nC# est un langage avec un système de types avancé, mais NullReferenceException est un problème fréquent. Vérifiez :
\n- \n
- Les vérifications
nullsont-elles utilisées (?.,??,??=) ? \n - Y a-t-il une gestion des exceptions (try-catch) là où c'est nécessaire ? \n
- Les exceptions ne sont-elles pas avalées dans un catch vide ? \n
Exemple de code dangereux :
\nvar user = GetUserById(id);\nConsole.WriteLine(user.Name); // Erreur si user == null\nVersion sécurisée :
\nvar user = GetUserById(id);\nConsole.WriteLine(user?.Name ?? "Invité");\n\n1.3. Performance et LINQ
\nLINQ est pratique, mais peut être inefficace. Vérifiez :
\n- \n
- Ne fait-on pas plusieurs passages sur la collection (par exemple,
.Where().Select().ToList()sur IQueryable) ? \n Any()est-il utilisé à la place deCount() > 0pour vérifier la présence d'éléments ? \n - Y a-t-il des matérialisations inutiles (
.ToList(),.ToArray()) au milieu d'une chaîne ? \n
Mauvais :
\nvar list = items.Where(x => x.IsActive).ToList();\nvar first = list.FirstOrDefault();\nMieux :
\nvar first = items.FirstOrDefault(x => x.IsActive);\n\n1.4. Async et Task
\nEn .NET, l'asynchrone est la norme. Regardez :
\n- \n
awaitn'est-il pas oublié devant un appel asynchrone ? \n - Y a-t-il des appels bloquants (
.Result,.Wait()) dans un contexte synchrone ? \n - La convention est-elle respectée : les méthodes asynchrones se terminent-elles par
Async? \n
Anti-patron :
\nvar data = GetDataAsync().Result; // Peut provoquer un deadlock\nCorrect :
\nvar data = await GetDataAsync();\n\n2. Comment donner un retour : avec douceur mais de manière constructive
\nMê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\n2.1. Utilisez des messages "je" et des questions
\nAu lieu de "Tu as écrit du mauvais code", dites "Il me semble que cette méthode pourrait être simplifiée. Qu'en penses-tu ?".
\nExemples de formulations :
\n- \n
- "Je ne suis pas