Buchtipp für Softwareentwickler

Nachdem ich neulich die Export-Funktion des All-in-one-event-caldendar-Plugins für Wordpres debuggen und fixen durfte habe ich mir den Code noch ein wenig näher angesehen und heftige Bauchschmerzen bekommen. Das in Frage kommende Codestück ist sehr verwirrend und was der Entwickler hier vorhatte erschließt sich mir nicht direkt.

Natürlich gibt es inline Kommentar vor der fraglichen Funktion:

Super, die erste Kommentarzeile hat keinerlei Nährwert. Besonders interessant ist auch die Beschreibung des Parameters „$export“. Ja, hier kann ich einstellen, ob der event für den Export erzeugt wird oder, ja was passiert im Fall wenn hier „false“ übegeben wird? Welchen Anwendungszweck hätte diese Funktion dann? Habe ich mit meinem schnellen Patch von neulich vielleicht jetzt einen korrekten ICAL-Export aber wenn ich neue Termine anlege passt es nicht mehr?

Eine Suche der Funktionsaufrufe im Gesamtcode des Plugins offenbart dann, dass sie lediglich einmal aufgerufen wird und hier der Paramter export auf „true“ gesetzt wird. Fazit: Aller Code der sich mit der Variablen „$export“ innerhalb dieser Funktion beschäftigt ist total unsinning und könnte in einer Refaktorierung des Codes dieses Plugins vollständig entfernt werden, weil er nicht gebraucht wird.

An dieser Stelle möchte ich den Entwicklern die so etwas produzieren einfach die Lektüre des folgenden Buches empfehlen: The Art of Readable Code von Dustin Boswell und Trevor Foucher das bei O’Reilly zu haben ist.  Hier ist sehr schön beschrieben, wie man seinen Code so schreibt, dass er von demjenigen, der ihn in 3 Monaten anfassen muss auch verstanden wird. Dieser jemand könnte man auch selbst sein.

Irgendwie ist es für mich erschreckend, dass ein Plugin welchs mittlerweile fast 500.000 mal runtergeladen wurde solche Code-Katastrophen enthalten kann. Wobei dieses Plugin nur exemplarisch für jede Menge Software steht die mir in der letzten Zeit untergekommen ist. Auch in den Tiefen des Linux-Kernels findet man Dinge die nicht unbedingt als Musterlösung durchgehen würden. Und wie es bei der Closed-Source-Konkurrenz aussieht möchte ich gar nicht überlegen, dort dürfte der Code zum Teil noch katastrophaler sein als dort, wo jeder auch mal gucken kann wie es um die Codequaltität steht.

[ratings]

3 Gedanken zu „Buchtipp für Softwareentwickler

  1. Ich nehme mich da nicht aus: QS kostet Geld und auch unsere Fachabteilungen wollen zum Termin X Ergebnisse sehen…

    Die Folge: Statt mir die Zeit zu nehmen um nach Termin X das Projekt nochmal zu bereinigen und die qualität zu verbessern, muss ich mich bereits mit dem nächsten Projekt befassen und der „Beta“-Code bleibt stehen…

  2. Pingback: Denn sie wissen nicht was sie tun | König von Haunstetten

  3. Pingback: Code Horror in Sicherheitssoftware | Plasisent

Kommentare sind geschlossen.