C/C++ Projektbegleiter: C/C++ Projekte planen, dokumentieren, bauen und testen [Broschiert]

Nachdem "Der C/C++ Projektbegleiter" bereits 2007 veröffentlicht wurde und es noch immer keine Rezension gibt, schreibe ich jetzt eine. Da es bisher keine Rezension gegeben hat, habe ich lange gezögert, das Buch zu erwerben, und glaube, dass es auch anderen so ergehen könnte.

Der Text des "Projektbegleiters" ist sehr gut lesbar, die englischsprachigen Begriffe sind nicht krampfhaft übersetzt, sondern bleiben, wenn es keine unmittelbar einleuchtende deutsche Formulierung dafür gibt, im englischsprachigen Original, sodass man immer versteht, um welchen Terminus technicus es gerade geht. Der Stil des Autors ist flüssig, so manche Formulierung deutet auf große Erfahrung im Abhalten von Kursen hin.

Der "Projektbegleiter" ist in vier Kapitel gegliedert. Im 1. Kapitel, "Programmierrichtlinien", beschreibt der Autor empfehlenswerte Verzeichnisstrukturen, Code-Organisation und etliches mehr, wie etwa von ihm empfohlene Namenskonventionen, also z.b. die Konvention, dem Namen von Member-Variablen von C++ ein "m_" voranzustellen, also z.B. "m_myMemberVariable".

Das Kapitel richtet sich also an Neulinge in C und insbesondere in C++. Meiner Meinung nach sollte da unbedingt ein Hinweis auf das Buch Coding Standards: 101 Rules, Guidelines, and Best Practices von Herb Sutter, dem langjährigen Vorsitzenden des "C++ Standard Committee", erfolgen. Die dort (in Item 0) vorgeschlagenen Namenskonventionen (etwa "myMemberVariable_") führen zu leichter lesbaren Programmen. Viel wichtiger sind aber andere dort zu findende Ratschläge, wie z.B. "Avoid Macros" (Item 16). Insbesondere wird dort vorgeschlagen, anstelle der alten C-Konstrukte STL zu verwenden (std::vector, std::string usw.- Item 76ff.). Auch die anderen Items sind für Personen, die erstmalig ein größeres C++-Projekt beginnen, von einigem Interesse. In C++ sollte iman nämlich anders als in C programmieren, damit man zumindest die Dinge, die in C oft schief laufen (z.B. String Buffer Overflow) vermeidet. Es bleiben dann noch immer genug Fehlerquellen, um ausreichend beschäftigt zu sein. :-)

Richtigerweise weist der Autor des "Projektbegleiters" darauf hin, dass die "ungarische Notation", also das Kodieren des Variablentyps im Variablennamen (Beispiel: pchFirstLetter wäre ein Pointer auf eine Variable vom Typ "char"), vermieden werden sollte. Diese Empfehlung ist heute gängiger Standard. Trotzdem denke ich, dass ein Blick in das (bei Amazon erhältliche) Buch More Joel on Software, Kap. 23, "Making Wrong Code Look Wrong" lohnend sein könnte. Dort beschreibt Joel Spolsky, wie man mit der "richtigen" ungarischen Notation z.B. die Fehlerhäufigkeit beim Kodieren einer Web-Applikation verringern kann.

Kapitel 2 beschreibt das Dokumentieren mit "Doxygen" im Detail. Soweit ich das beurteilen kann, ist offensichtlich der gesamte Inhalt der offiziellen Dokumentation wiedergegeben worden. Jedenfalls habe ich in dem Buch einige Details von Doxygen entdeckt, die mir beim Lesen der Dokumentation von Doxygen entgangen waren, wie z.B. das Erstellen von "Message Sequence Charts" mit dem (nicht zu Doxygen gehörigen, externen) Programm mscgen. Auch das parallele Erstellen von mehrsprachigen Dokumentationen wird gezeigt.

Auch Kapitel 3, das den Umgang mit "make" beschreibt, ist sehr vollständig und sehr verständlich geschrieben. Da ich make intensiver nutze als Doxygen, war der "Neuigkeitswert" dieses Kapitels aber für mich geringer.

Kapitel 4 beschreibt Unit Testing, und zwar für die Programmpakete CUNIT, CPPUNIT und Boost Test Library. Ich habe leider keine Erfahrung mit diesen Paketen. Für meine C++-Projekte habe ich bisher "Template Unit Test" (TUT) verwendet. Dieses Paket hat den Vorteil, nur aus header-Dateien zu bestehen. Es gibt also keine Binärbibliothek, die zur Durchführung der Tests einzubinden wäre. Auch werden keine Makros, sondern nur Templates verwendet. Meiner Meinung nach lohnt es sich also, einen Blick auf TUT zu werfen, wenn man ein Unit Test-Programm für C++ auswählen möchte.

Die Anhänge des "Projektbegleiters" stellen Kurzdokumentationen der vorgestellten Programme dar, die nach zu lösenden Aufgaben sortiert sind, was recht praktisch ist.

Zusammenfassend: Sofern man nicht schon jahrelange Erfahrung mit den vorgestellten Verfahrensweisen und Programmen hat, kann man mit dem Buch einiges an Zeit sparen - der Kaufpreis ist jedenfalls sehr schnell wieder zurückverdient. Das exzellente Preis-Leistungsverhältnis des Buches ist mir jedenfalls fünf Sterne wert.