ftblog

                Die 10 Gebote für C Programmierer
                    (von Henry Spencer)
                        [mit Anmerkungen in <code> Tags]
________________________________________________________________________________


01. Du sollst lint regelmässig anwenden; und studiere seine Verkündigungen mit
    Bedacht, denn oft übertreffen die Wahrhaftigkeit seiner Erkenntnisse und
    Urteile die eigenen.

Dies ist noch immer ein ein weiser Ratschlag. Auch wenn viele
der modernen Compiler einige dieser Sünden aufzuspüren vermögen.
Alte schwache Versionen von Lint mögen Probleme mit sich führen, oder
aber nicht verfügbar sein in exotischen Ländern. Es gibt andere
Helfer, wie Saber-C, Codecenter oder splint, ein aktuelles Lint.

'Regelmässig' heisst hier, du mögest deine tägliche Führung von ihm
beziehen; und hoffe nicht darauf dein Code werde von Lints Segen durch
einen jähen Akt der Buße teilhaftig werden. Lint auf ein Programm
anzuwenden, welches sich nie zuvor dessen Zuwendung erfreuen durfte,
ist zu vergleichen mit dem Ausmisten von Stallungen, welches man
seinem schlimmsten Feinde nicht wünschen würde.

'Studieren' meint nicht den sinnlosen Eifer jegliche Ausgaben des
Lints auszurotten; Solltest du es nicht zum Schweigen bewegen können,
so erkenne den Grund für seine Unzufriedenheit und verstehe welch
Besorgnis erregendes Zeichens es zu verdeutlichen sucht.


02. Du sollst keinem NULL Zeiger folgen, denn Chaos und Wahnsinn erwarten dich
    am Ende dieses Weges.

Offensichlich wurden die heiligen Schriften an dieser Stelle
fehlinterpretiert, da die Worte 'null pointer' hätten heissen sollen,
um Verwirrungen des Konzeptes der 'null pointer' und des Macros
'NULL' (mehr davon sogleich).
Denn so ist die Bedeutung der Worte einfach. Ein 'null pointer' zeigt
auf Gegenden die voll sind von Drachen, Dämonen, 'core dumps' und
zahlloser anderer unreiner Kreaturen, die sich daran ergötzen in dem
Programme herumzutrollen, solltest du ihren Schlaf stören.
Ein 'null pointer' zeigt nicht auf eine 0, von welcher Gattung auch
immer diese sei, auch wenn mancher blasphemischer Code dieses
pietätlos annehmen würde.


03. Du sollst die Art aller Funktionsargumente an die erwarte anpassen, falls
    sie das nicht schon sind; tue dies auch, solltest du der Meinung sein, es
    sei nicht von Nöten; denn sie nähmen grausame Rache, wenn du es am
    wenigsten erwartest.

Ein Programmieren soll die Typen Struktur seiner Sprache verstehen,
auf das ihn nicht grosses Unglück widerfahre. Denn im Gegensatz zu
den Ketzereien die von einigen Höhlenbewohnern der westlichen Küsten
vertreten werden, sind 'int' und 'long' nicht synonyme Typen.
Die Zeit ihrer Gleichheit in Grösse und Verkörperung ist kurz; das
Leid aber, welches diejenigen erwartet, die an die Austauschbarkeit
dieser glauben werde auf immer und ewig währen, alsbald 64-bit
Maschinen alltäglich werden.

Auch erkenne, gegensätzlich zum Glauben der rückständigeren Einwohner
der unreinen östlichen Sümpfe, hat 'NULL' keinen Zeiger Typ und muss
in dem korrekten Typ transformiert werden, wann auch immer es als
Argument einer Funktion Verwendung findet.

(
  Die Worte des Propheten Ansi, welche es erlauben 'NULL' mit
  einem Typ von 'void *' zu definieren, werden oft aus ihrem
  Kontext gerissen und missverstanden. Der Prophet erlaubte
  eine spezielle Ausnahme des Gebots, in Fällen grosser Not in
  stürmischen Landen. Wahrlich, ein rechtschaffendes Programm
  möge seinen eigenen Weg durch das Dickicht der Typen finden,
  ohne sich dabei faul auf diese selten verfügbare Ausnahme zu
  verlassen, um alle seiner Probleme zu lösen.
  Auf jeden Fall hat der grosse Gott Dmr, der C erschuf, in all
  seiner Weisheit C mit vielen Zeigerarten ausgestattet, nicht
  nur mit einer, weshalb es noch immer von Nöten ist, des
  Propheten NULL in den gewünschten Typ transformieren.
)

Man mag nun denken, daß der radikale neue Segen der 'Prototypen' das
Erfordernis der Vorsicht bezüglich der Argumentenarten eliminieren
würde. Aber nein, meine Brüder. Zuvorderst, wenn man mit der
verdrehten Fremdheit der Argumentenlisten variabler Länge konfrontiert
wird, kehrt dieses Problem zurück. Und er der nicht stark in seinem
Glauben, durch wiederholte Praxis, wird sicherlich dieser raffinierten
Falle zum Opfer fallen. Zweitens, die Weisen haben beobachtet, daß
der Verlass auf diese 'Prototypen' viele Türen zu absonderlichen
Fehlern öffnet; und gewiss hatten einige gehofft das 'Prototypen'
zur Fehlerprüfung genutzt würden, aber nicht das sie implizite
Transformationen auslösen. Zuletzt: der Verlass auf 'Prototypen'
führt heute zu grossen Misslichkeiten in der "wahren Welt", da viele
sich an die alten Wege und alten Compiler klammern (ob aus Wunsch oder
Notwendigkeit sei dahin gestellt), denn niemand kann wissen auf
welcher Maschine sein Morgen laufen solle.


04. Falls misratene Header Dateien nicht den Rückgabetyp seiner
    Bibliotheksfunktionen ausrufen, so rufe diese, mit akribischer Genauigkeit,
    selbst aus, oder schmerzliche Pein möge dein Programm befallen.

Der Prophet Ansi hat, in seiner Weisheit, vermerkt, daß man die
Erzeuger auspeitsche und durch die Pein von allerlei Bannsprüchen
verlange, daß sie Header Dateien erschaffen, die ihre Bibliotheks-
funktionen deklarieren. Denn wahrlich, nur sie wissen von der genauen
Form der Beschwörungsformeln die sich dazu eignen ihre Magie optimal
zu rufen.

Der Prophet fügte auch hinzu, daß es nicht weise sei (und das es dazu
auch in Länder der Verdammung und zu subtilen Bugs führt), wenn man
versuche diese Funktionen selbst zu beschreiben, wenn schon die
verfügbaren Header eben dieses perfekt täten.


05. Du sollst die Grenzen aller Strings, nein aller Arrays, prüfen, denn wo du
    'foo' eingibst, wird eines Tages jemand 'supercalifragilisticexpialidocious'
    übergeben.

Wie die Bücher über den Grossen Wurm demonstrieren, sollte als
Konsequenz dieses Gebots in Produktionscode, der robust zu sein habe,
gets() niemals Anwendung finden, denn dies ist wahrlich ein Werkzeug
des Teufels. Die Schnittstellen sollten die Knechte immer über die
Grenzen der Arrays informieren und Knechte, die solches Anraten
verschmähen oder sich in Stille nicht daran halten, mögen unverzüglich
in das Land von Rm geschickt werden, wo sie keinen weiteren Schaden
zu verursachen vermögen.


06. Falls eine Funktion verkündet sie setze einen Fehlercode, sollte sie von
    Schwierigkeiten ereilt werden, dann sollst du diesen Fehlercode prüfen;
    Ja, prüfe diesen auch, sollten die Tests die Grösse deine Codes
    verdreifachen, denn die Göttern sollen jede für ihre Arroganz strafen, die
    denken 'derlei Probleme könnten mich nie ereilen'.

Alle wahrlich Gläubigen wünschen einen besseren Mechanismus zur
Prüfung von Fehlern. Denn das explizite Testen von rückgegebenen
Werten ist ermüdent, ermüdent ins Extrem gehoben, und so ist die
Versuchung sie zu auszulassen ist gross.
Aber bis zu jenem fernen Tage der Erlösung gehe diesen langen
gewundenen Pfad mit Beharrlichkeit und Achtsamkeit, so daß Verkäufer,
Maschine und Software, von Verzückung überrascht, keine Gedanken an
den Tag vor der Mündlichen Prüfung oder dem Grossen Schritt zum
Klienten, verschwenden.

Gelegentlich, wie mit der ferror() Fähigkeit des stdio, ist es möglich
die Prüfungen zu verschieben bis ein gesammeltes Ergebnis getestet
werden könne. Dies führt oft zu kürzerem, klarerem Code.
Ferner solle auch der begeisterste Gläubige sich im Urteil vom
Handhaben völlig uninteressanter Fehler üben...
Aber sei auf der Hut, die Transformation zu 'void' ist ein
zweischneidiges Schwert, welches das eigene Blut ohne Reue vergießt.


07. Du sollst Bibliotheken studieren und nicht dem Neuerfinden dieser, ohne
    triftigen Grundes, ergeben. Möge dein Code kurz und lesbar sein, und mögen
    die Tage freundlich und produktiv werden.

Zahllos sind die ungewaschenen Heiden, die Bibliotheken verschmähen,
durch dumme und falsche Gründe verleitet. So wie beispielsweise der
blinden Verehrung des Kleinen Götzen (auch bekannt als 'Effizienz').
Obwohl es wahr ist, daß einige der Fähigkeiten der C-Bibliotheken
schlecht beraten waren, ist es im Grossen und Ganzen besser und
günstiger die Arbeit von anderen zu Nutzen, als darauf zu bestehen
das Rad neu zu erdenken. Doch du sollst deine grösste Sorge darauf
verwenden zu verstehen, was dir eine Bibliothek verspricht, und was
nicht; auf das er sich nicht Einrichtungen verlasse, die in der
Zukunft unter seinen Füssen verschwinden mögen.


08. Du sollst den Zweck und die Struktur deines Prgrammes für deinen Nächsten
    klar gestalten indem du den 'einzig wahren Klammerstil' nutzen sollst.
    Und mögest du den Stil auch nicht mögen, so nutze ihn doch, denn Kreativität
    sollte nur zum lösen von Problemen verwendet, und nicht zur Schaffung neuer,
    hübscher Hindernisse, für das Verständnis des Codes, verschwendet werden.

Oh, diese Worte erzeugten in der Vergangenheit einige Ungewissheit
unter Anfängern und Konvertiten, die die alten Weisheiten nicht
kennen. Der 'einzig wahren Klammerstil' ist der, den die ersten
Propheten, Kernighan und Ritchie, in ihren Schriften anwendeten. Immer
wieder wird er von Ungebildeten als schwer zu benutzen kritisiert,
obwohl die Wahrheit darin liegt, daß er etwas komplizierter zu
erlernen ist - aber danach wundervoll klaren und offensichtlichen Code
erzeugt - und vielleicht ein wenig anfällig für Arbeitsfehler ist.

Obwohl du denken magst, daß deine eigene Art zu Klammern zu klarerem
Code führen würde, so werden dir Nachfolger dafür keine Dankbarkeit
entgegen bringen; im Gegenteil, man wird dich beschimpfen und deine
Arbeit verfluchen; Im schlimmsten Falle würde die Kunde hiervon bis zu
einem deiner zukünftigen Arbeitgeber vordringen. Viele Gewohnheiten in
diesem Leben bestehen, da sich Reibungen verringern und die
Produktivität durch eine universelle Übereinkuft begünstigen; und ob
sie die optimale Wahl sind ist weit weniger wichtig. So ist das auch
bei der Wahl des Klammerstils.


09. Die externen Bezeichner sollen einzigartig in ihren ersten sechs Buchstaben
    sein; und sei dieses raue Benehmen auch verdrießlich, und mögen sich auch
    die Jahre auch scheinbar ohne Ende dahinziehen, in denen du darauf wartest
    seine Wahrhaftigkeit zu erkennen. So mögest du dem Wahnsinn entgehen, an
    jenem einen schicksalshaften Tage, an welchem du danach verlangest dein
    Programm auf einem alten System laufen zu lassen.

Auch wenn einige ungestüme Fanatiker schreien mögen: 'Nein! Das
Millenium war da, und dieser Spruch ist überholt und muss nicht
mehr unterstützt werden.'; aber wahrlich gibt es viele, viele uralte
Systeme in der Welt, und es ist der Erlass des gefürchteten Gottes
Murphy, das die nächste Arbeitsstelle auf einer solchen Maschine sein
möge. Während du schliefst, arbeitet er gegen dich. Erwache und sieh
dich vor.

Merke gut: es ist nicht nötig, das die Länge eines Bezeichners auf
sechs Zeichen begrenzt ist. Die einzige Forderung die die heiligen
Worte verlangen, ist die Einzigartigkeit der ersten sechs. Dies ist
nicht so schwer wie viele Behauptungen glauben machen wollen.


10. Schwöre ab, verleugne und entsage der abscheulichen Ketzerei, welche
    folgendene ungeheuerliche Behauptung vertritt: 'Alles in der Welt ist
    eine VAX!'; Und habe keinen Umgang mit den gottlosen Heiden, die jenem
    barbarischen Irrglauben anhängen. So mögen die Tage des Programms lang
    sein, auch wenn die Tage der Maschine kurz sind.

Diese spezielle Ketzerei kann fairerweise mit 'Alles in der Welt ist
ein Sun!' oder 'Alles in der Welt ist ein i386er!' (letzteres ist die
abscheuliche Erfindung des Satan) ausgetauscht werden, und trotzdem
finden alle Worte des Gebotes Anwendung. Hüte dich im Speziellen vor
der raffinierten und widerwertigen Aussage 'Alles in der Welt ist
32-bit!', welches fast wahr gewesen sein mag, aber in naher Zukuft
noch weniger zutreffend sein wird als zuvor.

________________________________________________________________________________


Das engliche Original dieses Textes sei hier einzusehen.
Ins Deutsche übersetzt wurden diese wahren Worte von Frank Terbeck.
Sollten dem werten Leser Verbesserungsvorschläge in den Sinn kommen, so lasse
er mich es wissen. Dies ist die erste Übersetzung der Schrift.