Code Complete: A Practical Handbook of Software Construction [Englisch] [Taschenbuch]

"Code Complete" richtet sich an Programmierer, die ihren Programmierstil verbessern moechten.

Der Autor gibt eine Fuelle von Tipps und Hinweisen, von der sinnvollen Variablenbenennung und Kommentierung bis hin zum Schreiben von fehlerrobustem Code und Tuning. Vereinzelt gibt es auch ganz konkrete Implementierungs-Hinweise, z.B. zum Aufbau von Tabellen oder der Speicherverwaltung, der Schwerpunkt des Buches ist aber eindeutig das stilistische Element der Programmierung.

Viele Codebeispiel sind eingestreut, sowohl positive, als auch negative ("Coding Horror"). Da die in dem Buch gegebenen Hinweise nicht an eine spezielle Programmiersprache gebunden sind, sind auch die Codebeispiele in immer wieder anderen Sprachen geschrieben, wie C++, Java, oder auch Visual Basic.

Jeder Programmierer duerfte in diesem Buch wertvolle Hinweise und Anregungen finden.

Steve McConnells Buch stellt einen Abriß über die Software-Entwicklung dar, angefangen beim Entwurf über Hinweise zu guten Variablennamen, bis hin zum Debugging und Codeoptimierung. Es ist in einem lockeren Stil geschrieben, der nicht jedermanns Geschmack sein dürfte. Es versucht den Anschein zu erwecken, als könne es zu den einzelnen Themenbereichen fundierte und tiefgreifende Informationen bieten, sein Niveau ist insgesamt jedoch sehr niedrig. Dies verschleiert der Autor durch ein Feuerwerk an Verweisen auf Studien und Zitaten aus anderen Quellen, die das Buch unter dem Strich nur aufblähen und wenig nutzen. Es ist bezeichnend, daß McConnell sich praktisch nicht auf eigene Erfahrungen stützt, sondern fast ausschließlich fremde Quellen verwendet - Ergebnis: Realitäts- und Praxisferne.

Der naive Leser wird dadurch beeindruckt, die Geduld fortgeschrittener oder gar professioneller Programmierer und IT-Profis wird jedoch auf eine harte Probe gestellt. Ihnen kann dieses Buch nur sehr wenig Neues bieten, und die raren für sie interessanten Stellen sind nur schwer zu finden. Anfängern kann es Anregungen und Hinweise zum Programmieren und über guten Programmierstil bieten, ist für diese jedoch nur bedingt empfehlenswert, da sie nicht zwischen wirklich wichtigen und weniger wichtigen Hinweisen unterscheiden können - die bereits erwähnten veilfältigen Zitate und Studien bieten ihnen trotz allem nicht genug Hintergrundinformationen, warum sie etwas so und nicht anders tun sollen.

Neben wenig hilfreichen Trivialitäten ("20 Prozent des Codes enthalten 80 Prozent aller Fehler") setzt sich der Autor nur wenig mit seinen Quellen auseinander bzw. verfälscht diese sogar:

Beispiel 1: Er zitiert eine Studie, derzufolge Programmstellen mit den meisten Kommentaren auch die meisten Fehler enthalten und die größten Kosten verursachen. Anstatt den logischen Schluß zu ziehen, daß normalerweise die komplexesten Teile eines Programmes fehlerträchtiger und teurer sind als die einfachen Teile, und daß die komplexen Teile zur Arbeitserleichterung auch die meisten Kommentare enthalten, wird angeführt, daß Programmierer komplizierten Code mit zu vielen Kommentaren versehen!

Beispiel 2: Unter anderem mit dem Hinweis auf "Wien wartet auf Dich!" von DeMarco und Lister stellt McConnell fest, daß die besten Programmierer eine Aufgabe 10 mal schneller erledigen könnten, als die schlechtesten. In "Wien" wird dies näher erläutert: Die verwendete Programmiersprache hatte kaum Einfluß auf das Ergebnis, lediglich Assembler-Programmierer schnitten deutlich schlechter ab. Möglicherweise waren die "schlechten" Programmierer ja gar nicht so schlecht, sondern nur aus irgendwelchen Gründen gezwungen, ihre Aufgaben in Assembler zu lösen? Hochsprachen wurden nun mal erfunden, um das Programmieren zu erleichtern und zu beschleunigen...

Beispiel 3: Steve McConnell erläutert anhand einer Studie von Xerox aus dem Jahre des Herrn 1964, wieviel Zeit Programmierer mit Programmieren, bei Meetings und anderen Tätigkeiten verbringen. Er gibt selbst zu, daß die Zahlen ziemlich alt sind, meint jedoch unbekümmert, dies täte ihnen keinen Abbruch. Wieso jedoch Zahlen aus dem letzten Jahrtausend - über 45 Jahre alt! - eines einzigen Unternehmens in der sich rapide verändernden Software-Industrie heute noch Gültigkeit besitzen sollen, wird nicht begründet...

Neben haarsträubenden Fehlern ("1.000.000 * 1.000.000 / 1.000.000 = 1"), die in vielen Büchern auftauchen können, wird hier und da gerne rhetorisch kräftig übertrieben - ein Beispiel zu schlechten Kommentaren enthielt unter anderem die Augenfarbe des Programmierers, war also nicht gerade realistisch. Um die Beispiele zwischen schlechtem und guten Code herauszustreichen, hält sich der McConnell auch nur ungern oder gar nicht an seine eigenen Ratschläge. So werden in einem Beispiel zu schlechter Zeigerprogrammierung kryptische Variablennamen verwendet; das Beispiel für gute Programmierung benutzt dagegen sprechende, und glänzt daher um so mehr. Solche rein rhetorischen Kniffe sind für den aufmerksamen Leser sehr störend.

Zusammenfassend: Das Buch könnte eine für Anfänger brauchbare Übersicht über die einzelnen Bereiche und Aspekte der Software-Entwicklung darstellen. Leider beschränkt es sich nicht auf dieses Thema, sondern versucht immer wieder, in den einzelnen Bereichen in die Tiefe zu gehen, und verliert sich dabei meist in nur wenigen Details, und verinfacht die Ding all zu sehr, ohne wirklich ein echtes Verständnis für die Hintergründe des jeweiligen Gebiets zu vermitteln.

Das Buch liefert einen guten Überblick und ist leicht zu lesen. Es geht nicht so sehr ins Detail, sonst wäre es natürlich noch viel dicker. Wenn man sich mit dem Thema eines Kapitels bereits näher beschäftigt hat, so wird man hier sicher nicht viel Neues finden. Hat man das nicht, so fasst dieses Buch die wichtigsten Informationen auf pragmatische Art zusammen und macht vor allem Appetit auf mehr.

Vom vorgeschlagenen Entwicklungsprozess her bildet das Buch einen gemäßigten Gegenpol zu Agile. Es betont an vielen Stellen die Wichtigkeit einer im Vorfeld sauber ausgearbeiteten Software-Architektur, kehrt dabei aber keineswegs die Vorzüge von iterativen Entwicklungsstrategien unter den Teppich.

An einigen Stellen war ich mit den Tabellen in der Ebook-Version unzufrieden. Z.B. waren manche Spalten nur halb sichtbar. Ich habe meines Wissens nichts an der Schriftart oder Größe meines Kindle verstellt.
Vielleicht hätte ich das tun sollen oder an diesen Stellen auf Querformat wechseln sollen?
So oder so geht dadurch vom Inhalt jedoch nichts verloren, da die wesentlichen Fakten ohnehin im Fließtext wiederholt werden.