ISBN 1-55615-484-4

Dieses umfangreiche Kompendium (ca. 850 Seiten) beleuchtet fast alle Aspekte der SoftwareEntwicklung und gilt mittlerweile im englischen Sprachraum als Standardwerk zu diesem Thema.

Ich stehe nicht positiv zu diesem Buch. Es ist zwar ein umfangreiches Kompendium von Konzepten und Ideen, die im Zusammenhang mit der SoftwareEntwicklung eine Rolle spielen, aber gleichzeitig ist es merkwürdig indifferent in den vielen existierenden Grauzonen. Egal, ob es um GOTOs, die Ungarische Notation, die optimale Länge von Funktionen geht, der Autor bezieht selbst so gut wie nie eine eigene Position und überläßt die Entscheidungen dem Leser. Zusätzlich scheint mir das Buch in vielen Punkten die Funktion eines Microsoft-internen Codex zu spielen, der hausinterne Praktiken sanktioniert. Damit scheint es mir kein besonders geeignetes Buch für jemand, der in die Thematik einsteigen will und nach Leitlinien sucht.

Ein typisch-merkwürdiges Beispiel aus dem Buch (es geht um Fehlermitteilungen die bei defensiver Programmierung in der Release-Version verbleiben können oder sollen):

See that the messages you leave in are friendly. If you leave internal error messages in the program, verify that they're in a language that's friendly to the user. In one of my early programs, I got a call from a user who reported that she'd gotten a message that read "You've got a bad pointer allocation, Dog Breath!" Fortunately for me, she had a sense of humor. A common and effective approach is to notify the user of an "internal error" and list a phone number the user can call to report it.

[(Im deutschsprachigen Buch:) Überprüfen Sie den Tonfall Ihrer Meldungen! Schauen Sie nach, ob Sie den Meldungstext, der im Programm verbleibt, Ihren Benutzern zumuten können. In einem meiner früheren Programme hatte ich diesem Punkt offenbar nicht die ihm gebührende Beachtung geschenkt und erhielt eines Tages einen Anruf von einer Benutzerin, die soeben mit der Meldung "Falsche Zeigerzuordnung, Du Volltrottel!" erfrischt worden war. Gott sei Dank verstand sie Spaß. Am besten teilen Sie dem Benutzer mit, daß ein "Interner Fehler Nr. soundso" aufgetreten ist, und daß man ihm unter einer bestimmten Telefonnummer weiterhelfen wird.]

-- HelmutLeitner

Ich würde nicht so kritisch sein: Manche Aussagen würde man nicht mehr so schreiben, manches vermißt man, manches ist veraltet, etc. Trotzdem ist allein der Versuch eine umfassende Sammlung von "best practices" zusammenzutragen, anerkennenswert und gibt so manche Anregung. Das zitierte Beispiel finde ich z.B. gar nicht schlecht: Unverständliche oder unfreundliche Fehlermeldungen schreiben so manche Adepten der Informatik - wenn man das Buch liest und mit der eigenen Praxis vergleicht, kann das dann Anstoß sein, den Benutzer, für den man immerhin das Programm schreibt, auch mit einer hilfreichen Fehlermeldung zu versorgen (und by the way, ich bin mir sicher, daß ihn die Zeigerzuordnung in Modul xy nicht interessiert :-)) -- JohannesDöbler?

Wahrscheinlich hast du Recht damit, dass meine Beurteilung zu kritisch ist (das ist ein alter Fehler von mir, den ich noch mehr bekämpfen muss). Ein sprechende Fehlermitteilung hilft ziemlich viel wenn es zum direkten Kontakt zwischen Anwender und Entwickler kommt (bei kleineren Projekten). Meist ergibt sich die Fehlerursache und eventuell ein Workaround direkt. Das hat gar nichts damit zu tun, dass den Anwender der Fehler interessiert, man kann einfach das Problem schneller lösen wenn man Zusatzinformationen (z.B. den Namen des Files, wo der Fehler auftrat) bekommt. Aber das Ganze war nur ein winziges, zufällig herausgegriffenes Beispiel, das ich gar nicht überbewerten will. Ein anderes Beispiel ist die Frage "sind kurze Funktionen weniger fehlerträchtig als lange Funktionen", das IIRC nach längerem Hin und Her sehr indifferent endet. Aus meiner praktischen Erfahrung und der Einschätzung vieler Experten ist jedoch eine starke Modularisierung bis hinunter zu den Einzelfunktionen und die Vermeidung von Redundanzen sehr wohl qualitätswirksam. -- hl