- [Rob Pike's] Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
[...]
Ken Thompson, the man who designed and implemented the first Unix, reinforced Pike's rule 4 with a gnomic maxim worthy of a Zen patriarch: When in doubt, use brute force. - -- Basics of the Unix Philosophy
Zu meinen Aufgabenbereichen gehört bei meinem Job auch das Portieren von altem Code auf unsere neue Plattform. Einer der größten Unterschiede dabei ist, dass sich der Compiler von GCC 3.x auf GCC 4.x geändert hat. Das bringt einige Probleme mit sich. Interessant finde ich dabei, wie die Probleme von den Leuten aufgenommen wurden, die für den ursprünglichen Code verantwortlich waren.
Ein fast schon klassisches Beispiel: in C++-Code wurde eine Klasse angelegt, die verschiedene Variablen enthält, die aber nicht initialisiert wurden. Der GCC 3.x hat die Speicherbereiche anscheinend mit Nullen gefüllt, der GCC 4.x erwartet vom Programmierer, dass er dort etwas genauer spezifiziert, was er eigentlich gemeint hat. Tut er dies nicht, wird (vermutlich aus Performancegründen) der Speicher dort auch nicht initialisiert. Dies hat zur Folge, dass die Software mal geht und mal nicht, je nachdem, was gerade zufällig an dieser Stelle im Speicher steht. So ziemlich jeder weiß, dass solche Fehler sind schwer zu finden sind. Erste Reaktion die ich auf den Hinweis bekommen habe, dass man das so besser nicht machen sollte: "Wieso hat denn den Fehler im GCC 4 noch keiner behoben?" Ich weiß bis heute nicht, ob diese Frage wirklich ernst gemeint war, oder doch nur Spaß... Meine sonstigen Erfahrungen lassen mich allerdings ersteres annehmen.
(Nicht nur) bei uns ein weiterer Klassiker: während des Kompilieren werden Warnungen noch und nöcher geworfen. Bei den größeren Einzelteilen sind sie im vierstelligen Bereich. Die Herangehensweise ist auch schon klassisch: "Wieso die Warnungen rausnehmen? Das Programm läuft doch." Natürlich wird es für einen schwer, selbst Code von besserer Qualität in ein solches Moloch einzufügen. Die Warnung vom eigenen Code gehen in dem Sumpf einfach unter. Ein Kollege hat das die Tage so beschrieben: wenn ein Haus irgendwo steht und die Scheiben heile sind, bleiben sie auch heile. Ist aber erst mal eine kaputt, geht es schnell, bis auch die anderen eingeschmissen werden.
Ebenfalls die Tage hat Micha im IRC mal den Link zu den "
Basics of the Unix Philosophy" gepostet. Ich habe mir mal das erste Drittel zu Gemüte geführt, bevor in die Details und Erklärungen abgedriftet wurde, und ich war überrascht, wie viel davon auf meine Ideen, Konzepte, Programme und Programmierstil zutrifft. Ich kannte zwar die Grundphilosophie von Unix, aber nicht diese "Faustregeln".
Bei dem größten Projekt, dass ich bisher maßgeblich gestemmt habe, und auch weiterhin zu stemmen gedenke, ist
SLART, eine Sammlung von Programmen, die Aspekte abdeckt, die mit einer Musiksammlung auf Festplatte zu tun haben. Kernstück ist dabei "Partyman", ein Audioplayer, der das Anwendungsprofil "Hintergrundbeschallung für eine Party" abdeckt. Es gibt automatisch einen Übergang zwischen zwei Stücken, wenn einmal "Play" gedrückt wurde gibt es solange Musik, bis "Stop" gedrückt wird, entweder aus einer Playliste oder, wenn diese leer ist, sucht ein Zufallsgenerator was raus, aber ohne etwas doppelt vom selben Interpreten zu spielen. Später kam dann zum Beispiel "Stripped", ein CD-Ripper, dazu. Dieser kann nun auf Wunsch ein frisch geripptes Stück automatisch in die Playliste von "Partyman" eintragen. Die Idee für jede Anwendung ein eigenes Programm zu schreiben ist einer der Grundgedankten von Unix. Die klassische "Windows-Ansatz" wäre gewesen "Partyman" um die Funktion des CD-Rippens zu erweitern. Leider wird dieser Ansatz auch dann gerne unter Unix in Angriff genommen, wenn das Programm über ein graphisches Benutzerinterface verfügt. Bei dieser Programmsammlung gibt es in dem Code, den ich dafür programmiert habe, keine Warnungen.
Ich halte mich einfach an eine kleine handvoll Regeln, von denen ich auch einige in den "Basics of the Unix Philosophy" wiedergefunden habe, die mir die Arbeit an dem Code, der mittlerweile auch schon in den letzten zwei Jahren gewachsen ist, doch stark erleichtern. Das bisschen Sorgfalt, dass ich in den paar Details an den Tag lege pflege ich nicht aus Fleiß, sondern aus Faulheit... sonst müsste ich echte Anstrengungen unternehmen, um den Überblick zu behalten.
Kommentare
:) meine Theorie! Die Wurzel allen Fortschritts ist die menschliche Faulheit. Aber den Überblick scheinen wir schon leider verloren zu haben...