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

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

Code-Review ist nicht nur eine Formalität, sondern ein mächtiges Werkzeug zur Verbesserung der Codequalität. In C++ ist das Review aufgrund der Komplexität der Sprache besonders wichtig: Manuelle Speicherverwaltung, Templates, Mehrfachvererbung. In diesem Artikel werden wir untersuchen, worauf man bei der Überprüfung von C++-Code achten und wie man Anmerkungen so formulieren sollte, dass sie hilfreich und nicht verletzend sind.

1. Speichersicherheit und RAII

Das Erste, was überprüft werden sollte, ist das Ressourcenmanagement. In C++ gibt es keinen Garbage Collector, daher sind Speicherlecks und doppelte Freigaben ein häufiges Problem. Das Schlüsselmuster ist RAII (Resource Acquisition Is Initialization).

Was prüfen:

\n
• Werden Smart Pointer (std::unique_ptr, std::shared_ptr) anstelle von rohen new/delete verwendet?
\n
• Gibt es manuelle delete-Aufrufe im Code? (Außer in seltenen Fällen von Low-Level-Arbeit)
\n
• Sind RAII-Klassen korrekt implementiert: Wird die Ressource im Konstruktor erfasst und im Destruktor freigegeben?
\n
• Wurde der virtuelle Destruktor in der Basisklasse nicht vergessen?
\n

// ❌ Schlecht: Manuelle Verwaltung\nvoid process() {\n    int* data = new int[100];\n    // ... wenn eine Ausnahme auftritt, Speicherleck\n    delete[] data;\n}\n\n// ✅ Gut: RAII mit std::vector\nvoid process() {\n    std::vector<int> data(100);\n    // sicher bei Ausnahmen\n}

Wie man Feedback gibt: Sagen Sie statt „Du hast vergessen, den Speicher freizugeben“: „Hier wäre es besser, std::vector oder std::unique_ptr zu verwenden – das gibt Ressourcen automatisch frei und macht den Code ausnahmesicher.“

2. Const-Correctness und Referenzen

C++ erlaubt es, explizit anzugeben, dass Daten nicht geändert werden sollen. Das verbessert die Lesbarkeit und ermöglicht dem Compiler eine bessere Optimierung des Codes.

Was prüfen:

\n
• Sind alle Parameter, die nicht geändert werden, mit const markiert?
\n
• Werden große Objekte per Konstante-Referenz (const T&) übergeben, anstatt per Wert?
\n
• Sind Methoden, die das Objekt nicht ändern, als const markiert?
\n
• Wird const_cast ohne zwingende Notwendigkeit verwendet?
\n

// ❌ Schlecht: Kopieren eines großen Objekts\nstd::string toUpper(std::string s); // Kopie\n\n// ✅ Gut: Konstante-Referenz\nstd::string toUpper(const std::string& s); // ohne Kopie\n\n// ❌ Schlecht: Methode nicht const, obwohl sie den Zustand nicht ändert\nclass Point {\n    int x, y;\npublic:\n    int getX() { return x; } // sollte const sein\n};\n\n// ✅ Gut\nint getX() const { return x; }

Wie man Feedback gibt: „Fügen wir const für Parameter hinzu, die nicht geändert werden – das macht die Schnittstelle klarer und verhindert versehentliche Änderungen.“

3. Verwendung von STL und Algorithmen

Die Standardbibliothek von C++ enthält viele vorgefertigte Lösungen. Das Neuerfinden des Rades ist ein häufiger Fehler von Anfängern.

Was prüfen:

\n
• Gibt es manuelle Schleifen, die durch Algorithmen ersetzt werden können (std::find, std::sort, std::transform)?
\n
• Ist der Container richtig gewählt? (std::vector für wahlfreien Zugriff, std::list für häufige Einfügungen in der Mitte)
\n
• Werden std::string_view zur Übergabe von Strings ohne Kopie verwendet?
\n
• Wurde reserve() für std::vector bei bekannter Größe nicht vergessen?
\n

// ❌ Schlecht: Manuelle Suche\nbool contains(const std::vector<int>& v, int val) {\n    for (size_t i = 0; i < v.size(); ++i) {\n        if (v[i] == val) return true;\n    }\n    return false;\n}\n\n// ✅ Gut: Verwendung von STL\nbool contains(c