In meinem Beruf komme ich sehr oft mit den Quelltexten vieler Kollegen in Kontakt, deren Programmierwerke ich lesen, verstehen und erweitern können muss. Man gewöhnt sich daran, dass jeder irgendwo seinen eigenen Stil hat, und dass eben jener manchmal besser und manchmal schlechter lesbar ist. Auch ich habe schon Code geschrieben, auf den ich nicht stolz bin, aber man lernt ja schließlich aus Fehlern. Umso amüsanter ist es, wenn man als erfahrener Entwickler hin und wieder zu lesen bekommt, was sich ein blutiger Anfänger so aus seinen Hirnwindungen drückt.

So geschehen vor einigen Monaten, als ein unerfahrener Praktikant (nennen wir ihn im Folgenden einfach „Praktikant“) eine unbedeutende Erweiterung für ein Softwareprojekt schreiben sollte, für das ich teilweise die Verantwortung trage. Ich gehe zwar nicht näher auf die Details der Implementierung ein, aber ich habe drei kleine kuriose Codeschnipsel gesammelt, die mir in seinem Quellcode so aufgefallen sind. Das ist übrigens derselbe Praktikant, der (um mir einen Screenshot zu zeigen) eine Bilddatei in ein leeres Microsoft Word-Dokument eingefügt hat, damit er das Dokument als PDF-Datei exportieren konnte, um es mir dann per E-Mail zu schicken.

Achtung, der folgende Beitrag könnte für Nicht-Programmierer äußerst uninteressant sein.

Fangen wir mit etwas Leichtem an. Die obige, mehrfach verschachtelte Collection beweist zwar, dass der Praktikant einen sicheren Umgang mit Collections haben muss, aber diese einzeilige Ausgeburt der Hölle beweist leider auch, dass er nicht weiß, dass man im Idealfall gegen Schnittstellen programmiert, und dass er es wohl gern übertreibt. Was auch immer in diesem „Ding“ gespeichert wird, es klingt jedenfalls nicht gesund.

Diese Zeile bekommt Sonderpunkte, weil ich darüber erst einen Augenblick nachdenken musste. Mal davon abgesehen, dass der Praktikant sich hier weder an die Namenskonvention für Boolean-Variablen hält, noch verstanden hat, dass eine Boolean-Variable bereits die Antwort auf die Frage ist, bestaunte ich die kreative logische Verknüpfung. Während ich mich ungläubig fragte, ob der Compiler einen „umgedrehten Ungleich-Operator“ wirklich durchgehen lässt, fiel mir dann doch auf, dass das eigentlich eine Zuweisung ist, wobei dem zugewiesenen Wert (false) ein NOT vorangestellt wird (also true). Dieser „Vergleich“ ergibt immer true, der IF-Block wird immer ausgeführt. Dieses Codekonstrukt ist absoluter Käse. Vielleicht wollte uns der Praktikant aber auch nur ein wenig erheitern.

Das ist der Gewinner in der Kategorie „Kreativster Schundcode“. Drei Dinge sind absolut bemerkenswert: Zunächst testet man immer mit dem Gleichheitsoperator (==) auf null, definitiv nicht mit equals. Außerdem testet man normalerweise deshalb auf null, weil man eine NullPointerException vermeiden möchte, während der Praktikant hier sogar noch selbst eine werfen will. Und überhaupt: Der Test auf null mit equals kann niemals funktionieren, denn wenn someObject tatsächlich null sein sollte, wird mit equals bereits implizit eine NullPointerException geworfen, wo versucht wird, explizit eine zu werfen. Für das Fazit lasse ich den von mir sehr geschätzten, leider kürzlich verstorbenen Harold Ramis als Dr. Egon Spengler zu Wort kommen: „Kurz, aber völlig sinnlos.“

Und dann war da noch dieser eine unwahrscheinliche „interne“ Fehler der Eclipse IDE, den ich wohl versehentlich verursacht habe, als ich während eines Debugging-Durchlaufs versuchte das Workbench-Fenster horizontal zu verkleinern. Die Fehlermeldung, die schon beinahe als Realsatire durchgehen könnte, lasse ich im Folgenden einfach mal für sich selbst sprechen: