Revue de code en C# : 7 choses qui énervent les développeurs seniors

Introduction : Pourquoi votre code fait-il tiquer le senior ?

Vous avez envoyé une pull request. Cinq minutes passent. Dans le chat, un message arrive : « Et si on réécrivait ce bloc ? » et une dizaine de commentaires sous chaque deuxième ligne. Ça vous parle ? Si vous codez en C# et travaillez en équipe, la revue de code n'est pas qu'une simple case à cocher dans Jira. C'est un moment de vérité.

J'ai rassemblé les remarques typiques que les seniors laissent lors d'une revue de code C#. Il ne s'agit pas de syntaxe, mais de réflexion. Il s'agit de transformer un « code qui fonctionne juste » en un code qu'on n'a pas envie de réécrire dès le premier vendredi.

C'est parti pour décortiquer les anti-patrons C# qui énervent même les chefs d'équipe les plus calmes.

1. Nombres magiques et chaînes de caractères : « Qu'est-ce que ça signifie ? »

Le commentaire le plus fréquent lors d'une revue de code C# concerne les nombres. Vous écrivez if (status == 3), et le senior demande immédiatement : « C'est quoi ce 3 ? C'est le statut "En traitement" ou "Supprimé" ? ».

Mauvais :

if (order.Status == 3 && days > 7)\n{\n    CancelOrder(order);\n}\n

Bon :

private const int OrderStatusCancelled = 3;\nprivate const int MaxDaysBeforeAutoCancel = 7;\n\nif (order.Status == OrderStatusCancelled && days > MaxDaysBeforeAutoCancel)\n{\n    CancelOrder(order);\n}\n

Encore mieux : le sortir dans une énumération. Les seniors adorent le code lisible où l'on n'a pas besoin de consulter la base de données pour comprendre la logique métier. C'est une règle de base de la revue de code C# : le code doit parler de lui-même.

2. Async void — le tueur silencieux d'applications

Si vous écrivez async void ailleurs que dans des gestionnaires d'événements (par exemple, dans WPF ou WinForms), préparez-vous à un gros point négatif. Async void ne peut pas être suivi — une exception tombera dans le vide et fera planter le processus.

Mauvais :

public async void LoadData()\n{\n    var data = await _repository.GetDataAsync();\n    // Si ça plante ici — l'application plante sans message d'erreur\n}\n

Bon :

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

Lors d'une revue de code C#, le senior pointera forcément ce point. Souvenez-vous : async Task est votre ami, async void est votre ennemi (sauf pour les événements).

3. Les classes Godzilla : Principe de responsabilité unique

Vous ouvrez un fichier, et il y a 2000 lignes. Une seule classe fait tout : elle accède à la base de données, envoie des emails, génère un rapport et prépare même le café. C'est un anti-patron C# classique — l'objet Dieu.

Le senior lors d'une revue de code C# dira : « Découpons cela en plusieurs classes ». Et il aura raison.

Exemple de violation :

public class OrderService\n{\n    public void ProcessOrder(Order order)\n    {\n        // 1. Validation\n        // 2. Sauvegarde en BDD\n        // 3. Envoi d'email\n        // 4. Journalisation\n    }\n}\n

Comment faire :

public class OrderProcessor\n{\n    private readonly IOrderValidator _validator;\n    private readonly IOrderRepository _repository;\n    private readonly INotificationService _notificationService;\n\n    public OrderProcessor(\n        IOrderValidator validator,\n        IOrderRepository repository,\n        INotificationService notificationService)\n    {\n        _validator = validator;\n        _repository = repository;\n        _notificationService = notificationService;\n    }\n\n    public async Task ProcessOrderAsync(Order order)\n    {\n        _validator.Validate(order);\n        await _repository.SaveAsync(order);\n        await _notificationService.SendConfirmationAsync(order);\n    }\n}\n

Ce n'est pas simplement « joli ». C'est testable. Vous pouvez simuler le dépôt et vérifier uniquement la logique de traitement. Le refactoring C# dans ce style est un must-have pour tout projet.

4. Les exceptions comme structures de contrôle