Code Review en C++ : quoi vérifier et comment donner un retour

Introduction : pourquoi un Code Review en C++ est nécessaire

Le code review (revue de code) est l'une des pratiques clés du développement professionnel. Dans le monde du C++, où les erreurs de gestion de la mémoire ou une mauvaise utilisation de la STL peuvent entraîner des bugs difficiles à détecter et des fuites, une revue de qualité devient cruciale. Il ne s'agit pas simplement d'une vérification de style, mais d'une recherche systématique de problèmes potentiels : des erreurs logiques aux violations du RAII (Resource Acquisition Is Initialization).

Dans cet article, nous allons voir sur quoi se concentrer lors d'un code review de code C++, comment formuler des remarques pour qu'elles soient utiles et non blessantes, et comment instaurer une culture de revue saine au sein de l'équipe.

Que vérifier lors d'un Code Review de code C++

La revue n'est pas une lecture de code comme un livre. C'est une analyse active. Utilisez la checklist suivante pour ne rien oublier d'important.

1. Sécurité de la gestion de la mémoire et RAII

Le C++ ne pardonne pas l'inattention envers les ressources. Vérifiez :

• L'utilisation de pointeurs intelligents (std::unique_ptr, std::shared_ptr) au lieu de new/delete bruts.
• L'absence de fuites mémoire si le code utilise des pointeurs bruts dans des scénarios complexes.
• Le respect du principe RAII : toutes les ressources (fichiers, sockets, mutex) doivent être encapsulées dans des classes avec un constructeur et un destructeur corrects.

// Mauvais : pointeur brut, gestion manuelle
void process() {
    int* data = new int[100];
    // ... oubli du delete[] — fuite
}

// Bon : pointeur intelligent
void process() {
    auto data = std::make_unique<int[]>(100);
    // la mémoire sera libérée automatiquement
}

2. Exactitude de l'utilisation de la STL et des algorithmes

La bibliothèque standard du C++ est puissante, mais il est facile de l'utiliser incorrectement.

• Vérifiez qu'une boucle manuelle n'a pas été écrite là où std::find, std::copy, std::transform pourraient être utilisés.
• Faites attention à l'invalidation des itérateurs (par exemple, après un push_back dans un std::vector).
• const est-il utilisé pour les références lorsque l'objet n'est pas modifié (const std::string& au lieu de std::string).

// Mauvais : copie de chaîne et recherche manuelle
bool hasValue(std::string s, char c) {
    for (size_t i = 0; i < s.size(); ++i) {
        if (s[i] == c) return true;
    }
    return false;
}

// Bon : référence const et algorithme
bool hasValue(const std::string& s, char c) {
    return std::find(s.begin(), s.end(), c) != s.end();
}

3. Règles du C++ moderne (C++11/14/17/20)

Les constructions obsolètes sont un signal d'alarme.

• Remplacement de typedef par using.
• Utilisation de auto pour les types complexes (mais pas partout — la lisibilité prime).
• Utilisation de nullptr au lieu de NULL ou 0.
• Vérification de l'utilisation de constexpr et noexcept là où c'est approprié.

4. Performance et architecture

Même un code correct peut être lent ou difficile à maintenir.

• Évitez les copies inutiles : passer de gros objets par valeur est une erreur fréquente.
• Vérifiez qu'une fonction virtuelle n'est pas appelée dans une boucle critique (sauf si justifié).
• Évaluez le couplage des classes : le code viole-t-il les principes SOLID.

Comment donner du feedback : les règles d'une revue constructive

La partie technique n'est que la moitié du travail. L'autre moitié est le facteur humain. Une remarque mal formulée peut démotiver l'auteur ou provoquer un conflit.

1. Séparez la critique du code de la personne

Parlez du code, pas du programmeur. Au lieu de « Tu as écrit un code horrible », dites « À cet endroit, il serait préférable d'utiliser un pointeur intelligent pour éviter une fuite ».

2. Utilisez le « pourquoi »