Innerhalb der letzten Woche habe ich mich mal wieder etwas intensiver mit einem meiner größeren Software-Projekte befasst, mit welchem ich vor annähernd zwei Jahren begonnen habe. Zwei Jahre sind eine lange Zeit und es kommt immer mal wieder komplett neuer Programm-code hinzu oder kleinere bzw. größere Teile werden überarbeitet. Derart frequentierter Programm-code kann somit völlig unterschiedliche Qualitäten haben und da ich dieses Projekt mit der Absicht die Programmiersprache Python etwas besser kennen zu lernen sowie in die GUI-Programmierung einzusteigen gestartet habe, spiegelt der Programm-code dieses Projekts einen großen Teil meiner Programmier-Fähigkeiten dar die sich über diese Zeit hinweg entwickelt haben.
Die letzte Woche war dementsprechend „abenteuerlich“, besonders wenn man in jene Bereiche vordringt die seit zwei Jahren kein Licht gesehen haben. Da vermisst man schmerzlichst irgendwelche Kommentare ober überhaupt jegliche Art von Dokumentation, denn die ist nicht allzu selten der einzige Hinweis darauf „warum“ etwas gemacht wird. Der Programm-code selber sagt einem nur wie und was er macht, aber das alleine reicht nicht wenn zum Beispiel aus anderen Gründen es das einzige „wie“ ist das auch funktioniert. Da hilft ein wohl platzierter Kommentar ungemein wenn man im Begriff ist genau das zu verändern und dann aus dem selben Grund wie vor zwei Jahren nach ein und demselben Fehler sucht..
Spätestens wenn Kommentare fehlen und noch dazu der Programm-code an sich sehr wirr gestaltet wurde, möchte man am liebsten alles löschen und neu schreiben, was meist wohl der einzig saubere wenn auch aufwändigste Weg ist. Für solche Fälle gibt es sogenannte „coding guidelines“, an die man sich nicht nur aus Rücksicht auf andere „Leser“ sondern auch aus Rücksicht auf sich selbst halten sollte. Die Namensgebung (Variablen, Funktionen, Klassen, etc.), Formatierung (Inline- und Block-Kommentare), Strukturierung (Lokale und Externe API bzw. Module) und unterschiedliche Einrückungsebenen sind nun einmal der direkteste Weg Programm-code verständlich zu gestalten.
Das absolute Nonplusultra allerdings sind immer noch Unit-Tests. Damit erschlägt man sogar gleich mehrere Dinge zugleich: Sie sorgen dafür dass jeder weiß „wie“ etwas zu benutzen ist, man kann Ausnahmefälle ganz leicht beschreiben (und spart sich somit die erneute Fehlersuche wenn man zwei Jahre später…) und solange man nichts daran ändert „was“ gemacht wird kann man sich gediegen zurücklehnen, falls noch alles funktioniert.
Ich jedenfalls werde versuchen mich weiterhin daran zu halten, besonders wenn ich alles lösche und neu schreibe. 😀
0 Kommentare
Trackbacks/Pingbacks