C++-Code, den man Kollegen zeigen kann: Code-Style und Konventionen

Wenn „es funktioniert“ nicht die Hauptsache ist

Stellen Sie sich folgende Situation vor: Sie öffnen einen fremden Pull-Request in C++. Der Code kompiliert, die Tests bestehen, die Logik ist korrekt. Aber Sie brauchen 40 Minuten, um zu verstehen, was passiert. Variablen heißen a, b, ptr2, Einrückungen springen zwischen 2 und 8 Leerzeichen, und in einer Datei sind snake_case und camelCase gemischt. Kommt Ihnen das bekannt vor?

In der Einzelentwicklung ist ein solches Chaos noch zu verkraften. Aber sobald ein zweiter, dritter oder zehnter Entwickler am Projekt beteiligt ist, verwandelt das Fehlen eines einheitlichen Code-Styles für C++ den Code in einen „Sumpf“. Jeder schreibt so, wie er es gewohnt ist, und die Zeit für Code-Reviews steigt exponentiell.

In diesem Artikel analysieren wir, welche C++-Konventionen im Team wirklich funktionieren, wie man sie schmerzfrei einführt und warum dies Nerven und Geld spart. Los geht's!

Warum Code-Style nicht „schön“, sondern eine Geldfrage ist

Viele denken, dass Diskussionen über Codestil Zeitverschwendung sind. In der Praxis zeigen Studien (z. B. von Google und Microsoft): Die Lesbarkeit des Codes wirkt sich direkt auf die Anzahl der Fehler aus. Wenn ein Entwickler weniger Aufwand für das Entschlüsseln des Geschriebenen aufwenden muss, macht er seltener Fehler beim Refactoring und findet Probleme schneller.

Ein einheitlicher C++-Codestandard bietet dem Team drei entscheidende Vorteile:

\n
• Schnelligkeit beim Onboarding. Neue Teammitglieder müssen nicht raten, wie hier geschrieben wird – sie schauen sich einfach eine beliebige Datei an und erkennen das Muster.
\n
• Minimale Konflikte im Code-Review. Statt „Schreib die Einrückung um“ diskutieren Sie Architektur und Logik.
\n
• Automatisierung. Formatierer und Linter übernehmen die Routine und geben dem Gehirn Raum für Kreativität.
\n

Die gute Nachricht: Sie müssen das Rad nicht neu erfinden. Es gibt bewährte Best Practices für C++, die an jedes Projekt angepasst werden können.

Grundlegende C++-Konventionen: Von Namensgebung bis Formatierung

Gehen wir die wichtigsten Bereiche durch, die in einem Code-Style-Guide festgelegt werden sollten. Zu jedem Punkt gebe ich ein Beispiel für „schlecht“ und „gut“.

1. Namensgebung: snake_case vs. CamelCase vs. PascalCase

In C++ hat sich historisch ein hybrider Ansatz etabliert. Die Standardbibliothek verwendet snake_case, viele Unternehmen (Google, Microsoft) bevorzugen dies ebenfalls für Variablen und Funktionen. Für Klassen und Strukturen wird häufiger PascalCase verwendet.

Beispiel für eine schlechte Namensgebung:

class datamanager {\n    int numberOfElements;\n    void ProcessData(int* ptr) { ... }\n};

Probleme: Klasse in snake_case, Methode in CamelCase, kein Kontext. Besser so:

class DataManager {\n    int number_of_elements_;\n    void ProcessData(int* data_ptr) { ... }\n};

Was hier korrigiert wurde:

\n
• Klasse – PascalCase.
\n
• Felder – snake_case mit Unterstrich-Suffix für private Member (Google-Stil).
\n
• Methode – PascalCase (oder snake_case, wenn im Team so üblich).
\n
• Parameter – snake_case mit Suffix _ptr, damit sofort klar ist, dass es sich um einen Zeiger handelt.
\n

Tipp: Wählen Sie einen Stil für das gesamte Projekt. Die Mischung von getValue() und get_value() in einer Datei führt garantiert zu Verwirrung.

2. Formatierung: Leerzeichen, Klammern und Zeilenlänge

Die häufigste Quelle für Streitigkeiten: Wo soll die öffnende Klammer stehen – in derselben Zeile oder in der nächsten? In C++ ist es üblich, sie in derselben Zeile zu setzen (K&R-Stil), aber es gibt Variationen.

Beispiel für einen konsistenten Stil:

void CalculateSum(const std::vector<int>& values) {\n    int sum = 0;\n    for (size_t i = 0; i < values.size(); ++i) {\n        sum += values[i];\n    }\n    return sum;\n}

Hier ist alles einheitlich: Klammer nach if, fo