Programmierperlen
Programmieren ist eine ernste Angelegenheit. Meistens jedenfalls. Seit Jahrzehnten kursieren unter Programmiererinnen und Programmierern kurze Regeln, Erfahrungswerte und Ratschläge, die irgendwo zwischen Softwaretechnik, Lebensweisheit und trockenem Informatikerhumor liegen.
Eine bekannte Sammlung solcher „Programmierperlen“ veröffentlichte Jon Bentley 1985 unter dem Titel Bumper-Sticker Computer Science. Viele der Sprüche sind inzwischen rund vierzig Jahre alt – und manche wirken erstaunlich aktuell.
-
Jeder Narr kann Code schreiben, den ein Computer versteht.
Gute Programmierer schreiben Code, den Menschen verstehen.“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Martin Fowler, Refactoring: Improving the Design of Existing Code, 1999, S. 15; später in die Auswahl der JavaRanch Granny aufgenommen.
-
Debugge Code – Kommentare können lügen.
“Debug only code – comments can lie.”
JavaRanch Granny. Die Kurzfassung greift einen Ratschlag von Dave Storer aus Bentleys Sammlung auf: Kommentare können irreführen – entscheidend ist der tatsächlich ausgeführte Code.
-
Wenn du zu viele Sonderfälle brauchst, machst du etwas falsch.
“If you have too many special cases, you are doing it wrong.”
Craig Zerouni; in Jon Bentley, Bumper-Sticker Computer Science (1985) und More Programming Pearls (1988); auch JavaRanch Granny.
-
Bring zuerst deine Datenstrukturen in Ordnung – dann schreibt sich der Rest des Programms fast von selbst.
“Get your data structures correct first, and the rest of the program will write itself.”
David Jones; in Bentley 1985/1988; auch JavaRanch Granny.
-
Tests können zeigen, dass Fehler da sind – aber nie, dass keine da sind.
“Testing can show the presence of bugs, but not their absence.”
Nach Edsger W. Dijkstra; in Bentleys Sammlung und bei JavaRanch Granny. Dijkstras ursprüngliche Formulierung stammt bereits aus Notes on Structured Programming (1970).
-
Der erste Schritt beim Reparieren eines kaputten Programms:
Bring es dazu, zuverlässig kaputtzugehen.“The first step in fixing a broken program is getting it to fail repeatedly.”
Tom Duff; in Bentleys Sammlung; auch JavaRanch Granny.
-
Den schnellsten Algorithmus kann man oft durch einen ersetzen, der fast genauso schnell ist – und viel leichter zu verstehen.
“The fastest algorithm can frequently be replaced by one that is almost as fast and much easier to understand.”
Douglas W. Jones; in Bentley 1985/1988; auch JavaRanch Granny.
-
Die billigsten, schnellsten und zuverlässigsten Teile eines Computersystems sind die, die gar nicht da sind.
“The cheapest, fastest, and most reliable components of a computer system are those that aren't there.”
Gordon Bell; in Bentleys Sammlung; auch JavaRanch Granny.
-
Hektische Betriebsamkeit ersetzt kein Verständnis.
“Furious activity is no substitute for understanding.”
H. H. Williams; in Bentleys Sammlung Bumper-Sticker Computer Science.
-
Benutze den Computer nicht für Dinge, die sich von Hand effizient erledigen lassen.
“Don't use the computer to do things that can be done efficiently by hand.”
Richard Hill; in Bentley 1985/1988; auch JavaRanch Granny.
-
Je früher du anfängst zu programmieren, ohne vorher nachzudenken, desto länger dauert es.
“The sooner you start to code, the longer the program will take.”
Roy Carlson; in Bentleys Sammlung Bumper-Sticker Computer Science. Die Ergänzung „ohne vorher nachzudenken“ wurde in der deutschen Fassung hinzugefügt, um die Pointe unmittelbar verständlich zu machen.
-
Die ersten 90 % des Programms brauchen die ersten 90 % der Entwicklungszeit.
Die restlichen 10 % brauchen die anderen 90 %.“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
Tom Cargill; bekannt als die „Ninety-Ninety Rule“, in Bentleys Sammlung Bumper-Sticker Computer Science.
-
Belüg den Computer – und er wird sich rächen.
“If you lie to the computer, it will get you.”
Perry Farrar; in Bentley 1985/1988; auch JavaRanch Granny.
-
In jedem großen Programm steckt ein kleines Programm, das raus will.
“Inside of every large program is a small program struggling to get out.”
C. A. R. Hoare; bekannt als „Hoare's Law of Large Programs“; auch JavaRanch Granny.
Woher stammen die Programmierperlen?
1985 bat der Informatiker Jon Bentley die Leserinnen und Leser seiner Kolumne Programming Pearls in den Communications of the ACM um kurze Ratschläge zur Programmierarbeit – möglichst knapp genug für einen Autoaufkleber. Im September 1985 veröffentlichte er eine Auswahl unter dem Titel Bumper-Sticker Computer Science.
Bentley weist dabei selbst darauf hin, dass die genannten Namen häufig die Personen bezeichnen, die ihm einen Spruch eingesandt haben – nicht unbedingt dessen ursprüngliche Urheber. Die Sammlung sollte daher eher als überlieferte Programmierfolklore denn als Sammlung wissenschaftlicher Lehrsätze verstanden werden.
Eine erweiterte Fassung erschien 1988 als Kapitel 6 in More Programming Pearls: Confessions of a Coder. Viele Jahre später stellte die „JavaRanch Granny“ daraus eine persönliche Auswahl zusammen, die im Laufe der Zeit verändert und um weitere Programmierweisheiten ergänzt wurde.
Quellen
Jon Bentley:
„Programming Pearls: Bumper-Sticker Computer Science“,
Communications of the ACM,
Band 28, Nr. 9, September 1985, S. 896–901.
DOI: 10.1145/4284.315122
Jon Bentley:
More Programming Pearls: Confessions of a Coder,
Addison-Wesley, 1988,
Kapitel 6 „Bumper-Sticker Computer Science“, ab S. 57.
ISBN 0-201-11889-0
JavaRanch:
Programming Pearls – Granny's current list.
Persönliche Auswahl auf Grundlage der 1985 veröffentlichten Sammlung,
später ergänzt und verändert.





