Code Review in C++: Was man prüfen und wie man Feedback geben sollte

Einleitung: Warum Code Review in C++ wichtig ist

Code Review ist eine der wichtigsten Praktiken in der professionellen Softwareentwicklung. In der Welt von C++, wo Fehler bei der Speicherverwaltung oder die falsche Verwendung der STL zu schwer auffindbaren Bugs und Speicherlecks führen können, wird ein qualitativ hochwertiges Review entscheidend. Es geht nicht nur um eine Stilprüfung, sondern um die systematische Suche nach potenziellen Problemen: von logischen Fehlern bis hin zu Verstößen gegen RAII (Resource Acquisition Is Initialization).

In diesem Artikel besprechen wir, worauf man bei einem Code Review von C++-Code achten sollte, wie man Anmerkungen formuliert, damit sie hilfreich und nicht verletzend sind, und wie man eine gesunde Review-Kultur im Team etabliert.

Was man bei einem Code Review von C++-Code prüfen sollte

Ein Review ist nicht das Lesen von Code wie ein Buch. Es ist eine aktive Analyse. Verwenden Sie die folgende Checkliste, um nichts Wichtiges zu übersehen.

1. Speichersicherheit und RAII

C++ verzeiht keine Unachtsamkeit bei Ressourcen. Prüfen Sie:

• Werden intelligente Zeiger (std::unique_ptr, std::shared_ptr) anstelle von rohen new/delete verwendet?
• Gibt es Speicherlecks, wenn der Code in komplexen Szenarien rohe Zeiger verwendet?
• Wird das RAII-Prinzip eingehalten: Alle Ressourcen (Dateien, Sockets, Mutexe) sollten in Klassen mit korrektem Konstruktor und Destruktor gekapselt sein.

// Schlecht: roher Zeiger, manuelle Verwaltungvoid process() {    int* data = new int[100];    // ... delete[] vergessen — Speicherleck}

// Gut: intelligenter Zeigervoid process() {    auto data = std::make_unique<int[]>(100);    // Speicher wird automatisch freigegeben}

2. Korrekte Verwendung von STL und Algorithmen

Die Standardbibliothek von C++ ist mächtig, aber leicht falsch anzuwenden.

• Prüfen Sie, ob eine manuelle Schleife geschrieben wurde, wo std::find, std::copy, std::transform verwendet werden könnten.
• Achten Sie auf die Ungültigmachung von Iteratoren (z. B. nach push_back in einem std::vector).
• Wird const für Referenzen verwendet, wenn das Objekt nicht geändert wird (const std::string& statt std::string).

// Schlecht: Kopieren des Strings und manuelle Suchebool hasValue(std::string s, char c) {    for (size_t i = 0; i < s.size(); ++i) {        if (s[i] == c) return true;    }    return false;}

// Gut: const-Referenz und Algorithmusbool hasValue(const std::string& s, char c) {    return std::find(s.begin(), s.end(), c) != s.end();}

3. Regeln des modernen C++ (C++11/14/17/20)

Veraltete Konstrukte sind eine rote Flagge.

• Ersetzung von typedef durch using.
• Verwendung von auto für komplexe Typen (aber nicht überall — Lesbarkeit ist wichtiger).
• Anwendung von nullptr anstelle von NULL oder 0.
• Prüfung auf constexpr und noexcept, wo angemessen.

4. Leistung und Architektur

Selbst korrekter Code kann langsam oder schwer wartbar sein.

• Vermeiden Sie unnötige Kopien: Die Übergabe großer Objekte per Wert ist ein häufiger Fehler.
• Prüfen Sie, ob eine virtuelle Funktion in einer heißen Schleife aufgerufen wird (falls nicht gerechtfertigt).
• Bewerten Sie die Kopplung von Klassen: Verstößt der Code gegen die SOLID-Prinzipien?

Wie man Feedback gibt: Regeln für konstruktives Review

Der technische Teil ist die eine Hälfte. Die andere Hälfte ist der menschliche Faktor. Eine falsch formulierte Anmerkung kann den Autor demotivieren oder einen Konflikt auslösen.

1. Trennen Sie Code-Kritik von der Person

Sprechen Sie über den Code, nicht über den Programmierer. Sagen Sie statt „Du hast schrecklichen Code geschrieben“ lieber „An dieser Stelle sollte man besser einen intelligenten Zeiger verwenden, um ein Speicherleck zu vermeiden“.

2. Verwenden Sie „Warum“