9 schlechte Programmiererangewohnheiten (die eigentlich jeder liebt)

Michael Thomas

© Shutterstock.com/Lukatme

Oft sind es die kleinen Regelverstöße und Grenzübertretungen, oder das Verputzen von Nahrungsmitteln, von denen wir ganz genau wissen, dass jeder Bissen uns dem Sensenmann garantiert näher bringt, die ihren ganz eigenen Reiz ausmachen. Gleiches gilt auch für Programmierregeln: Es sind gerade die schlechten Angewohnheiten, die viele lieben.

Der Technologie-Autor Peter Wayner hält Verstöße gegen manche der hehren Regeln der Programmierkunst gar für nützlich: Auch wenn es mit Gefahren verbunden sein kann, können als Folge ihrer Missachtung auch Vorteile wie etwa eine schnellere bzw. einfachere Arbeitsweise oder saubererer Code winken.

Angewohnheit Nummer 1: Goto verwenden

In den Frühzeiten von Fortran oder BASIC stellte der Goto-Befehl die teilweise einzige Möglichkeit zur Programmierung von Verzweigungen dar, was allerdings zu Spaghetticode führte. Der Wegbereiter der strukturierten Programmierung Edsger Dijkstra sprach im Jahr 1968 mit seinem Aufsatz „Go To Statement Considered Harmful“ gar eine Art Bann über Goto aus. Auch break, return und Co. sind umstritten. Die Praxis zeigt jedoch, dass die Goto-Alternativen zu sehr aufwändigen Konstrukten führen können, weshalb einige, wie etwa Donald E. Knuth, Goto für die optimale Lösung üblicher, insbesondere zeitkritischer, Programmierprobleme halten.

Angewohnheit Nummer 2: Auf Dokumentation verzichten

Manche Funktionen und sogar manche Klassen sind aufgrund ihres Namens (z. B. deleteAll) mehr oder weniger selbsterklärend. Die Auswahl des richtigen Namens kann, so Wayner, einer Dokumentation sogar überlegen sein, da diese nur an einem Ort zu finden ist, während die Funktionen an anderen Stellen des Codes auftauchen können. Manchmal, so Wayner weiter, kann eine Dokumentation sogar nachteilig bzw. gar gefährlich sein: Beispielsweise dann, wenn sich der Code rasch ändert und Code und Dokumentation voneinander abweichen.

Lesen Sie auch: Weniger reden, mehr tun – Schluss mit den Meetings!

Angewohnheit Nummer 3: Zu viel Code in einer Zeile

Spendiert man beispielsweise jeder Aktion oder jedem Step eine eigene Zeile, so kann dies Wayner zufolge handfeste Vorteile haben: So wird etwa das Debugging leichter. Der Nachteil liegt logischerweise darin, dass der Code dadurch deutlich länger wird – man muss deutlich mehr scrollen, um eine Vorstellung vom Code zu gewinnen.

Angewohnheit Nummer 4: Typen nicht festlegen

Manche der neueren Compiler sind in der Lage, den Datentyp durch einen „Blick“ auf den Code zu erschließen. Sie gehen den Code von vorne bis hinten durch, bis sie sich der Variablen sicher sind. Im Zweifelsfall setzen sie ein Error Flag. Die einfacheren Deklarationen können Wayners Ansicht nach also weggelassen werden, was den Code etwas sauberer macht.

Angewohnheit Nummer 5: Jo-Jo-Code

Jo-Jo-Code, also Code, der einen Wert in eine andere Repräsentation und wieder zurück konvertiert, ist Wayner zufolge im Grunde schrecklich ineffizient, weshalb viele Programmierer ihr Design darauf ausrichten, möglichst wenig Konvertierungen durchzuführen. Allerdings nennt Wayner Ausnahmen von dieser Regel: Beispielsweise könnte eine besonders leistungsstarke proprietäre Bibliothek nur Strings annehmen, was einen zur Konvertierung zwingt. Oder es ist schlicht weniger zeitaufwändig, den Code hin und her zu konvertieren, selbst wenn es Tage und Wochen dauert, als den kompletten Code umzuschreiben.

Angewohnheit Nummer 6: Eigene Datenstrukturen schreiben

Manchmal, so Wayner, passt eine gegebene Standard-Datenstruktur einfach nicht richtig zum eigenen Code. So kann man etwa von einer Bibliothek dazu gezwungen werden, den Code vor Nutzung der Struktur zu rekonfigurieren. Eine eigene Datenstruktur zu schreiben, kann Wayner zufolge in solch einem Fall deutlich schneller von der Hand gehen und, da der Code für die Reformatierung entfällt, sogar für saubereren Code sorgen.

Angewohnheit Nummer 7: Schleifen unterbrechen

Eine Untermenge des „Verbots“ von Goto: Eine gängige Regel lautet, dass jede Schleife eine Invariante haben sollte, d. h. eine logische Anweisung, die über die Ausführung der Schleife hinweg wahr ist. Ist sie nicht mehr wahr, endet die Schleife. Der Nachteil dieser Regel besteht für Wayner darin, dass sie die Verwendung von return oder break in einer Schleife verbietet, was in der Praxis gewöhnlicherweise zu komplexerem Code führt.

Angewohnheit Nummer 8: Kurze Variablennamen verwenden (ausgenommen i, x und and)

Die gängige Programmierregel lautet, dass jeder Variablenname beschreibt, welchem Zweck sie dient. Manche Java-Programmierer haben dies, so Wayner, zum Anlass genommen, mit Hilfe von Binnenmajuskeln wahre Monster von Namen zu erschaffen. Manchmal bieten sich Wayner zufolge stattdessen auch einbuchstabige Variablen an: Fähige Programmierer dürften ihm zufolge zum Beispiel erkennen, dass sich hinter i ein Iterator verbirgt.

Angewohnheit Nummer 9: Operatoren und Funktionen umdefinieren

Manche Sprachen erlauben es dem User, Elemente, die so erscheinen, als seien sie konstant, umzudefinieren (z. B. kann man in Python 2.7 via TRUE=FALSE die Bedeutung beider vertauschen) – für Wayner zwar potentiell gefährlich, aber auch raffiniert einsetzbar: Zum Beispiel dann, wenn ein großer Codeblock umgearbeitet werden muss. Oder der gesamte Code einem anderen Zweck dienen soll.

Aufmacherbild: Unhealthy and fat food composition von Shutterstock / Urheberrecht: Meryll

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "9 schlechte Programmiererangewohnheiten (die eigentlich jeder liebt)"

avatar
400
  Subscribe  
Benachrichtige mich zu:
struberg
Gast

ad arg 1 (GOTO) und 7 (break): Natürlich sollte man es vermeiden. Aber ohne break und goto (oder halt labels mit break wie in Java) sind die meisten Sprachen eben nicht turing-complete! Siehe BPEL, das ist eben leider dadurch in der Praxis oft extrem mühsam – ok, nicht nur deswegen 😉

House, Greg
Gast
Die meisten Beispiele für schlechte Programmierangewohnheiten, die hier aufgeführt werden, bestehen nur aus billigen Klischee-Sprüchen und das ohne eine wirkliche Begründung anzuführen. Vor allem den Goto Befehl so zu verteufeln, ist einfach nur sinnloses Nachgeplappere von Leuten die nie wirklich damit gearbeitet haben und deswegen – statt selbst nachzudenken – infantile und abgedroschene Phrasen wie „Spagetticode“ und dergleichen zu verwenden. Statt alles zu glauben was hier so an Klischees nachgeäfft wird, empfehle ich den Leuten die diesen Artikel lesen, erst einmal selbst nachzudenken und sich eine eigene Meinung zu bilden. Was der Autor scheinbar nicht getan hat und stattdessen einfach… Read more »