Revue de code C++ : ce que les seniors regardent en premier

Introduction : pourquoi votre revue se transforme-t-elle en champ de bataille ?

Vous avez soumis une Merge Request. Tout semble propre, la logique est correcte, le code compile. Une heure plus tard, vous recevez une réponse du senior : « -10 points pour Gryffondor » et 35 commentaires pour 200 lignes de code. Cela vous dit quelque chose ?

La revue de code en C++ n'est pas simplement une vérification de syntaxe. C'est un art qui sépare les juniors des seniors. Le C++ donne au développeur un immense pouvoir sur la mémoire et les performances, mais un grand pouvoir implique une grande responsabilité envers le comportement indéfini et les fuites de ressources.

Dans cet article, nous allons nous plonger dans la tête d'un relecteur expérimenté. J'ai rassemblé les remarques réelles que les seniors laissent lors des code review dans des projets de production. Si vous écrivez en C++ et souhaitez que vos PR soient acceptées du premier coup — lisez attentivement. Et si vous êtes team lead — utilisez cette checklist pour l'onboarding des nouveaux.

1. Se tirer une balle dans le pied : la gestion manuelle de la mémoire

Le sujet de discorde le plus fréquent en revue — « pourquoi n'utilises-tu pas les pointeurs intelligents ? ». Les seniors détestent les new et delete bruts en C++ moderne (C++11 et plus récent).

Mauvais exemple

class DataProcessor {\n    int* buffer;\n    size_t size;\npublic:\n    DataProcessor(size_t s) : size(s) {\n        buffer = new int[s]; // Qui va supprimer ?\n    }\n\n    ~DataProcessor() {\n        delete[] buffer; // Et si une exception est levée dans le constructeur ?\n    }\n};

Commentaire du senior : « Violation du RAII. Si le constructeur lève une exception après l'allocation mémoire — le destructeur ne sera pas appelé. Fuite mémoire. Utilise std::vector ou std::unique_ptr. »

Bon exemple

class DataProcessor {\n    std::vector<int> buffer;\npublic:\n    explicit DataProcessor(size_t s) : buffer(s) {}\n};

Les seniors adorent le RAII (Resource Acquisition Is Initialization). Si vous écrivez new dans votre code, soyez prêt à expliquer pourquoi std::make_unique ou std::vector ne vous conviennent pas. Dans 95% des cas, ils conviennent.

2. Const-correctness : mettez-vous une « virgule »

Un const manquant est un chiffon rouge pour tout développeur senior en C++. Ce n'est pas qu'une question de style, c'est un contrat avec le lecteur du code et le compilateur.

Ce qui énerve en revue

std::string getName() { // Pourquoi pas const ?\n    return name;\n}\n\nvoid printData(std::vector<int>& data) { // Copie ? Référence ? Modifie ?\n    for (auto& item : data) {\n        std::cout << item;\n    }\n}

Commentaire du senior : « La méthode getName() ne modifie pas l'objet — rends-la const. Le paramètre data n'est pas modifié — passe-le en const std::vector<int>&. Sinon, le code appelant ne sait pas si tu vas modifier ses données ou non. »

Correction

std::string getName() const { // méthode const\n    return name;\n}\n\nvoid printData(const std::vector<int>& data) { // référence const\n    for (const auto& item : data) {\n        std::cout << item;\n    }\n}

La règle est simple : si une méthode ne modifie pas l'état de l'objet — const. Si une fonction ne modifie pas un argument — const T&. La const correctness en C++ n'est pas une option, c'est un standard.

3. Sémantique de déplacement : copier n'est pas notre religion

Le C++ moderne repose sur le déplacement, pas la copie. Les seniors repèrent immédiatement où vous créez des copies inutiles et tuez les performances.

Mauvais pattern

std::vector<int> processData(std::vector<int> data) { // Copie en entrée\n    // ... beaucoup de logique ...\n    return data; // Copie en sortie ? Ou NRVO ?\n}\n\nvoid caller() {\n    std::vector<int> bigData = {1, 2, 3, ... 1000000};\n    auto result = processData(bigData); // Encore une copie !\n}

Comm