Goldene Programmier-Regeln

  1. Erst denken, dann programmieren
  2. So einfach wie möglich
  3. Keine Tricks und Schweinereien
  4. Ein funktionierendes, langsames Programm ist mehr wert, als ein schnelles, fehlerhaftes Programm.
  5. Sofort kommentieren, nicht nachträglich
  6. bei Änderungen schlechten Code wegschmeißen und neu schreiben
  7. Warn-Level des Compilers so hoch wie möglich
  8. Warnungen des Compilers immer beachten

Anmerkungen:

  1. Bitte keine "Trial&Error"- Methode zur Programmentwicklung einsetzen. Am besten seine Gedanken erst mal zu Papier bringen, ehe man sie in den Rechner reinhackt. Damit findet schon ein erstes "Code-Reading" beim Eingeben seiner Aufschriebe statt, was dem Programm nur zugute kommen kann (einfach mal ausprobieren!).
  2. Perfektion ist nicht dann erreicht, wenn nichts mehr hinzuzufügen ist, sondern wenn nichts mehr entfernen werden kann.
    3. (aus: die Bazarmethode)
  3. Eine wunderschöne Sammlung für abschreckende C-Programme findet man beim IOCCC (International Obfuscated C Code Contest). Wer sich verewigen will, kann es hier tun und nicht bei der alltäglichen Programmierarbeit.
  4. Vor der Effizienz eines Programms sollte man sich zuerst Gedanken über die Richtigkeit und Lesbarkeit eines Programms bzw. Programm-Entwurfs machen. Eine Verbesserung der Performance sollte erst nach dem korrekten Funktionieren in Angriff genommen werden. Oftmals reicht es aus, nur die Teile eines Programms zu tunen, die oft aufgerufen werden (innerste Schleife, Hilfsfunktionen).

    5. Effizienz-Anforderungen sollten im Design berücksichtigt werden. Die Möglichkeiten, durch Programmierung zu tunen, werden oft überschätzt ("Micro-Effiktivität", s. Glenford J. Myers: SW Reliability - Principles and Practices).
  5. Vor allem sollte man auch Randbedinugen und evtl. Bugs kommentieren.
  6. Der Aufwand, sich in schlechten Code einzuarbeiten und reinzudenken, ist meist um einiges höher als bei einer Neuimplementation. Diese sollte dann natürlich so lesbar geschrieben und kommentiert sein sollte, dass weitere Änderungen ohne große Einarbeitung und Gerhirnverrenkungen möglich sind.
  7. Das muss nicht unbedingt der höchste Warn-Level sein, aber es sollte der höchstmögliche Warn-Level sein,. Auf gar keinen Fall sollte man die Warnungen abschalten
  8. Warnungen des Compilers sind immer potentielle Fehlerquellen und sollten nicht auf die leichte Schulter genommen werden.
Autor: Oliver Böhm
letzte Änderung: 18. April 1999