Schlagwort-Archive: Compiler

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:

internalerror_eclipse

Ich dachte bis heute morgen noch, ich sei mittlerweile lange genug Java-Entwickler, um vor solchen blöden Fehlern gefeit zu sein. Stellt sich heraus, dass man wirklich viel Zeit mit sinnloser Fehlersuche selbst in simpelstem Code verschwenden kann.

Heute schrieb ich etwas in meiner favorisierten Java-IDE Eclipse, das ich in der Art praktisch täglich unzählige Male schreibe:

List<String> myList = new ArrayList<String>();

List und ArrayList wurden mir rot unterstrichen, weil er die Klassen nicht kannte. Es dauert natürlich nur wenige Klicks und Eclipse generiert die fehlenden Imports blitzschnell. So weit so normal. Doch dann wird mir List erneut rot unterstrichen, mit der Fehlermeldung „The type List is not generic; it cannot be parameterized with arguments <String>„.

Ungläubig starrte ich die Fehlermeldung an. Ich war mir eigentlich total sicher, dass List Generics verwendet. Sicherer ging es fast nicht. Die Fehlermeldung sagte also genau das Gegenteil von dem aus, was meiner Ansicht nach den Tatsachen entsprechen sollte. Oder doch nicht? Plötzlich begann ich zu zweifeln. Werde ich etwa schon senil? Wieso ist ArrayList parametrisierbar, aber List auf einmal nicht? Ist das irgendwie sinnvoll?

Ich begann hilflos, die Zeile irgendwie zu modifizieren. War List auf einmal allergisch gegen String geworden? Nein, daran lag es nicht, auch andere Parameter nahm er nicht an. Ich hätte den Parameter weglassen können, oder ich hätte auch direkt ArrayList anstelle von List verwenden können, das hätte funktioniert, aber Eclipse sollte mich doch nicht etwa dazu kriegen, die wichtigsten Programmierparadigmen zu vergessen. Ich vermutete, dass Eclipse einfach mal wieder seine Tage hatte und mich zu Unrecht irgendwelcher Anfängerfehler beschuldigte. An der Zeile war alles in Ordnung, postulierte ich.

Ich begann also doch das Orakel von Google zu bemühen, weil ich offenbar außer Stande war, mir selbst bei solch einem trivialen Problem zu helfen. Eine Quelle behauptete nun, dass es wohl mit dem Compliance-Level des Compilers zu tun hatte, das versehentlich auf eine Version vor Java 1.5 gestellt sein musste, also bevor Generics in Java eingeführt wurden. Ein kurzer Blick in die Compiler-Optionen des Projekts widerlegte das. Mit dem Compliance-Level war alles in Ordnung. In Zukunft also wieder auf konkrete Implementierungen programmieren?

Zum Glück nicht, denn des Rätsels Lösung fand ich direkt im Anschluss, und ich bin erschrocken über die Tatsache, dass ich an dieser Stelle vielleicht erst ganz zuletzt gesucht hätte. Ich habe mich bei den Imports entweder verklickt oder Eclipse hat mich einfach nur auf den Arm nehmen wollen. Als ich List importieren wollte, habe ich wie automatisch die oberste Option ausgewählt, weil das in dem Fall normalerweise immer funktioniert. Ausnahmsweise dachte Eclipse, es wäre besonders witzig wenn ganz oben die wenig bekannte java.awt.List stehen würde, anstelle der sehr viel häufiger genutzten gleichnamigen Klasse java.util.List.

Nun, die AWT-List verwendet tatsächlich keine Generics, Eclipse hat also Recht behalten. Aber der Fehler ist so dämlich, dass es mir eine Lehre war, die Imports allzu leichtfertig zu handhaben. Künftig prüfe ich höchstpersönlich jede einzelne importierte Klasse auf Richtigkeit.