C++-Code-Review: Woran Senioren zuerst hängen bleiben

Einleitung: Warum wird Ihr Review zum Schlachtfeld?

Sie haben einen Merge Request gesendet. Alles scheint sauber, die Logik ist korrekt, der Code kompiliert. Eine Stunde später kommt die Antwort vom Senior: „-10 Punkte für Gryffindor“ und 35 Kommentare zu 200 Codezeilen. Kommt Ihnen das bekannt vor?

Ein C++-Code-Review ist nicht nur eine Syntaxprüfung. Es ist eine Kunst, die Junioren von Senioren unterscheidet. C++ gibt dem Entwickler enorme Macht über Speicher und Leistung, aber mit großer Macht kommt große Verantwortung für undefiniertes Verhalten und Ressourcenlecks.

In diesem Artikel werfen wir einen Blick in den Kopf eines erfahrenen Reviewers. Ich habe echte Anmerkungen gesammelt, die Senioren bei Code-Reviews in Produktionsprojekten hinterlassen. Wenn Sie in C++ programmieren und möchten, dass Ihre PRs beim ersten Mal angenommen werden – lesen Sie aufmerksam. Und wenn Sie Teamleiter sind – nutzen Sie diese Checkliste für das Onboarding neuer Mitarbeiter.

1. Eigentor: Manuelle Speicherverwaltung

Der häufigste Streitpunkt im Review – „Warum verwendest du keine intelligenten Zeiger?“. Senioren hassen rohe new und delete im modernen C++ (C++11 und neuer).

Schlechtes Beispiel

class DataProcessor {\n    int* buffer;\n    size_t size;\npublic:\n    DataProcessor(size_t s) : size(s) {\n        buffer = new int[s]; // Wer wird löschen?\n    }\n\n    ~DataProcessor() {\n        delete[] buffer; // Was, wenn eine Ausnahme im Konstruktor?\n    }\n};

Kommentar des Seniors: „Verstoß gegen RAII. Wenn der Konstruktor nach der Speicherzuweisung eine Ausnahme auslöst – wird der Destruktor nicht aufgerufen. Speicherleck. Verwende std::vector oder std::unique_ptr.“

Richtiges Beispiel

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

Senioren lieben RAII (Resource Acquisition Is Initialization). Wenn Sie new im Code schreiben, seien Sie bereit zu erklären, warum std::make_unique oder std::vector für Sie nicht geeignet sind. In 95 % der Fälle sind sie es.

2. Const-Correctness: Setzen Sie sich ein „Komma“

Ein fehlendes const ist ein rotes Tuch für jeden C++-Senior-Entwickler. Es ist nicht nur Stil, es ist ein Vertrag mit dem Leser des Codes und dem Compiler.

Was im Review nervt

std::string getName() { // Warum nicht const?\n    return name;\n}\n\nvoid printData(std::vector<int>& data) { // Kopie? Referenz? Ändert?\n    for (auto& item : data) {\n        std::cout << item;\n    }\n}

Kommentar des Seniors: „Die Methode getName() ändert das Objekt nicht – mach sie const. Der Parameter data wird nicht geändert – übergib const std::vector<int>&. Sonst weiß der aufrufende Code nicht, ob du seine Daten änderst oder nicht.“

Wir korrigieren

std::string getName() const { // const-Methode\n    return name;\n}\n\nvoid printData(const std::vector<int>& data) { // const-Referenz\n    for (const auto& item : data) {\n        std::cout << item;\n    }\n}

Die Regel ist einfach: Wenn eine Methode den Zustand des Objekts nicht ändert – const. Wenn eine Funktion das Argument nicht ändert – const T&. Const correctness in C++ ist keine Option, sondern ein Standard.

3. Move-Semantik: Kopieren ist nicht unsere Religion

Modernes C++ dreht sich um Verschieben, nicht um Kopieren. Senioren sehen sofort, wo Sie unnötige Kopien erstellen und die Leistung beeinträchtigen.

Schlechtes Muster

std::vector<int> processData(std::vector<int> data) { // Kopie am Eingang\n    // ... viel Logik ...\n    return data; // Kopie am Ausgang? Oder NRVO?\n}\n\nvoid caller() {\n    std::vector<int> bigData = {1, 2, 3, ... 1000000};\n    auto result = processData(bigData); // Noch eine Kopie!\n}

Kommentar