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

Code review en C# : par où commencer et quoi chercher

Le code review (révision de code) n'est pas qu'une simple formalité, mais un outil puissant pour améliorer la qualité du projet et la croissance de l'équipe. Pour les développeurs débutants en C#, le processus de vérification du code des autres suscite souvent de la peur : « Et si je rate un bug ? », « Comment dire à un collègue que son code est mauvais ? ». Dans cet article, nous allons voir sur quoi se concentrer lors d'une code review dans les projets .NET et comment donner un feedback de manière à être entendu, sans offenser.

Nous ne parlerons pas des évidences comme les erreurs de syntaxe – le compilateur les détecte. Notre objectif est d'apprendre à repérer les problèmes d'architecture, de lisibilité et de performance, ainsi qu'à formuler correctement les remarques.

1. Architecture et principes SOLID en C#

La première chose à vérifier dans le code C# est de savoir s'il respecte les principes SOLID. Même dans une petite méthode, on peut constater une violation du principe de responsabilité unique (Single Responsibility).

Ce qu'il faut vérifier :

• Taille des méthodes et des classes. Si une méthode fait plus de 20 à 30 lignes, elle fait probablement trop de choses. Suggérez de la diviser en plusieurs méthodes privées.
• Inversion des dépendances. Les classes ne doivent pas créer leurs dépendances via new. Utilisez plutôt l'injection de dépendances (DI). Exemple de mauvais code :

// Mauvais : la classe crée elle-même la dépendancepublic class OrderService{    private readonly EmailSender _sender = new EmailSender();

    public void ProcessOrder(Order order)    {        // logique...        _sender.SendEmail(order.CustomerEmail);    }}

La bonne version – via une interface et DI :

// Bon : la dépendance est injectéepublic class OrderService{    private readonly IEmailSender _sender;

    public OrderService(IEmailSender sender)    {        _sender = sender;    }

    public void ProcessOrder(Order order)    {        // logique...        _sender.SendEmail(order.CustomerEmail);    }}

• Principe de substitution de Liskov (LSP). Les classes dérivées ne doivent pas briser le comportement de la classe de base. Par exemple, si vous avez une classe Bird avec une méthode Fly() et que vous créez Penguin : Bird, c'est une violation du LSP, car les pingouins ne volent pas. Il est préférable de définir une interface IFlyable.

2. Gestion des erreurs et exceptions en .NET

C# dispose d'un système d'exceptions puissant, mais les débutants l'utilisent souvent de manière incorrecte. Lors d'une code review, faites attention aux points suivants :

• Blocs catch vides. Un code comme catch (Exception) { } est une bombe à retardement. L'erreur est avalée et vous ne saurez jamais qu'il y a un problème. Toujours journaliser l'exception ou la relancer.
• Exceptions trop générales. Attraper Exception est une mauvaise pratique. Essayez d'attraper des types spécifiques : SqlException, InvalidOperationException, etc.
• Utilisation des exceptions pour le contrôle de flux. N'utilisez pas try-catch à la place de if-else. Exemple de mauvais code :

// Mauvais : exception utilisée comme partie de la logiquetry{    int.Parse(userInput);}catch (FormatException){    Console.WriteLine("Format invalide");}

La bonne version – int.TryParse() :

// Bon : vérification sans exceptionif (int.TryParse(userInput, out int result)){    // travailler avec result}else{    Console.WriteLine("Format invalide");}

3. Performance et gestion de la mémoire

Pour les développeurs débutants en C#, le sujet de la performance reste souvent en arrière-plan. Cependant, la code review est un excellent moment pour signaler des constructions inefficaces.

Problèmes typiques :

• Allocations