jtb.blog

Für die Uni bin ich z.Z. an einem größeren Projekt: eine vorhandene Software in Java um S/MIME-Funktionen erweitern.
Diese Software heißt ZOË und hängt sich zwischen Mailclient und Mailserver - gut beschrieben unter ZoE - Mail-Aggregator.

Der erste Blick auf den Code zeigte schon, dass der Code nicht allzu schön ist, aber nach ein paar Wochen Coding zeigt sich, dass der Code einfach grottenschlecht ist. Eigentlich ein Wunder, dass es nicht von außen zu erkennen ist.

Best of schlechtem Code und schlechtem Codestyle:

• eine .jar einbinden und dann im eigenen Projekt neue, eigene Klassen im Namespace des Jars erstellen


• String-Konstanten einfach im Code schreiben


• reger Gebrauch von Reflektion


• um weniger Variablen zu haben - einfach alle Properties in einer HashMap per String-Konstante im Code speichern

Ein schönes Beispiel:
eine SZTable ist dafür da, eine Collection als Tabelle im Webbrowser darzustellen, Code zur Erzeugung einer solchen SZTable sieht so aus:


mehr nicht! Die Elemente sind in der Collection this.trustedCertificates() - die Frage ist jetzt nur, wie werden die Elemente angezeigt?
über "keysDescription" gibt der Programmierer an, welche Attribute der Objekte in "list" angezeigt werden wollen.. SZTable ruft also dann per Reflection z.B. getSubjectDN, getNotAfter oder getSerialNumber auf! Da freut man sich richtig wenn sich mal was an den Klassen ändert

Gleichzeitig erkennt man an dem Beispiel, dass SZTable für wichtige Attribute keine eigenen Accessoren hat, sondern alles über eine HashMap übergeben wird..


btw: für die Verlinkung eines Elements (also ein a href="...") braucht es ca. 10 Zeilen Code:


Also Finger weg von ZOË - der Programmierer mag zwar mit dem Code umgehen können und teilweise geniale Code-Abschnitte programmiert haben, aber für andere Programmierer kaum wart- und erweiterbar. Schade eigentlich da das Programm auf einer guten Idee basiert.