Code Review C# : checklist et bonnes pratiques pour un code sain

Code Review en C# : bien plus qu'une formalité, un rempart pour la production

Avez-vous déjà vu du code qui fonctionne, mais dont la simple lecture vous donne envie de fermer les yeux ? Des « nombres magiques », des boucles imbriquées, du async void et des null là où ils n'ont rien à faire. Le code review en C# n'est pas une procédure bureaucratique, c'est la dernière ligne de défense avant qu'un bug ne parte en production. Ou, pire encore, avant que vos collègues ne doivent maintenir ce code en maudissant son auteur.

Dans cet article, nous allons décortiquer les points essentiels à vérifier lors d'une revue de code C#. Pas de blabla, uniquement des cas concrets, des anti-patrons et des exemples. Si vous êtes junior, considérez ceci comme votre checklist. Si vous êtes senior, une petite piqûre de rappel ne fait jamais de mal. C'est parti.

1. Null : l'ennemi juré du développeur C#

Le célèbre NullReferenceException est à l'origine de millions de nuits blanches. La première chose à vérifier lors d'un code review : la protection contre null.

Qu'est-ce qui doit vous alerter ?

\n
• L'absence de vérification de null avant d'accéder à des propriétés.
\n
• Le retour de null par des méthodes censées retourner une collection.
\n
• L'ignorance des contextes nullable (#nullable enable).
\n

Mauvais :

public string GetUserName(User user)\n{\n    return user.Name.ToUpper(); // user peut être null !

Bon (C# 8+) :

public string GetUserName(User? user)\n{\n    return user?.Name?.ToUpper() ?? "Inconnu";\n}

Conseil pour le code review : exigez l'activation de Nullable dans les nouveaux projets. Ce n'est pas juste une mode, ça évite des erreurs stupides. Un code review C# sans vérification des nullable, c'est comme conduire sans ceinture de sécurité.

2. Async/await : l'asynchrone sans les pièges

La programmation asynchrone en C# est un outil puissant, mais mal utilisée, elle se transforme en bombe à retardement. En revue, nous vérifions trois péchés capitaux.

Péché n°1 : async void

Les méthodes async void sont impossibles à tracer — une exception atterrit dans le thread final et tue le processus. Elles ne sont acceptables que pour les gestionnaires d'événements (ex : un bouton dans WinForms).

Mauvais :

public async void LoadDataAsync()\n{\n    var data = await _service.GetDataAsync(); // Une erreur tue le processus\n}

Bon :

public async Task LoadDataAsync()\n{\n    var data = await _service.GetDataAsync();\n}

Péché n°2 : Blocage du code asynchrone

Utiliser .Result ou .Wait() dans un contexte asynchrone mène tout droit au deadlock.

Mauvais :

var result = _service.GetDataAsync().Result; // deadlock dans les applications UI

Bon :

var result = await _service.GetDataAsync();

Péché n°3 : Absence de CancellationToken

Les opérations longues doivent pouvoir être annulées. Si la signature d'une méthode ne contient pas de CancellationToken, demandez à l'auteur : « Que se passe-t-il si l'utilisateur ferme l'onglet ? »

3. LINQ : élégance ou lenteur mortelle ?

LINQ, c'est élégant. Mais le code review révèle souvent que derrière cette élégance se cache du O(n²) ou de multiples parcours de collection.

Erreurs typiques lors d'une revue de code C# avec LINQ :

\n
• Parcours multiple : .Count() > 0 + .First() = deux parcours. Utilisez .Any() et .FirstOrDefault().
\n
• ToList() oublié : le chargement paresseux peut exécuter la requête SQL après la fermeture du DataReader.
\n
• Where + Select redondants : si un seul SelectMany suffit, utilisez-le.
\n

Exemple qui doit faire lever un drapeau rouge :

var result = l