Zustandsforschung

Der Artikel 7 tips on writing clean code ist eine großartige Übersicht, wie man mit kleinen Verbesserungen sauberen Code produzieren kann. Der Autor führt die folgenden Punkte auf:

1. Immer wissen, warum man eine Exception fängt
Ein wichtiger Hinweis, aber nicht gerade einfach umzusetzen. Das Problem dabei ist eben gerade den richtigen Zeitpunkt dafür zu erwischen, wann man eine Exception fangen soll. Da könnte man eigentlich einen eigenen Artikel drüber schreiben. Grundsätzlich gilt aber: Niemals leere Catch-Blöcke verwenden! Auch nicht solche mit einem Kommentar wie “// Should never happen”. Es kann durchaus mal vorkommen, dass man der Meinung ist, eine Exception kann nie geworfen werden. Dann kann man aber immer noch folgendes machen:

    try {
        ...
    } catch (Exception e) {
        // Should never happen
        throw new RuntimeException(e);
    }

Damit ist man dann auf der sicheren Seite.

2. Nicht mit konkreten Klassen arbeiten, wenn es nicht nötig ist
Speziell für Java gilt hier: Es gibt einen Grund, warum es Interfaces gibt. Aber ich denke, über diesen Punkt kann man sich auch streiten. Insgesamt halte ich persönlich das nicht für so wichtig.

3. Sinnvolle Variablennamen verwenden
Ich glaube hier ist das Problem einfach die Faulheit der Programmierer. Ein Variablenname “s” für einen String mag im ersten Moment völlig offensichtlich erscheinen, aber spätestens wenn man selbst nach 3 Wochen wieder in den Code schaut, wünscht man sich meistens, man hätte doch lieber “userName” verwendet.

4. Copy & Paste
Dazu muss ich glaube ich nicht viel sagen. Wahrscheinlich die meistgenutzte Programmiertechnik, aber trotzdem keine gute. Kopierter Code bedeutet meistens auch kopierte Bugs.

5. Vernünftige Verwendung lokaler Variablen
Da fällt mir ein lustiges Beispiel aus meinem letzten Projekt dazu ein, wo ein Entwickler in ECMA-Skript eine Variable zunächst als String deklariert hat diese und im Laufe der Funktion zunächst als Integer und dann als Stream wiederverwendet hat.

6. Keine Rückgabewerte verwenden, die man nicht benötigt
Allgemeiner lässt sich das noch formulieren als: Keine Variablen deklarieren, die man nicht verwendet. Moderne Entwicklungsumgebungen weisen aber meistens auf solche Probleme hin.

7. Nicht benötigten Code weglassen
Ich sehe immer wieder auskommentierte Blöcke im Code. Dabei ist es doch eigentlich so einfach: Entweder ich brauche den Code noch, dann hat er nicht auskommentiert zu sein. Oder ich brauche ihn nicht mehr, dann lösche ich ihn. Sollte der unwahrscheinliche Fall eintreten, dass ich den Code doch noch mal benötige, dann kann ich ihn mir immer noch aus dem CVS oder Subversion zurückholen.

Ich kann diesen Punkten – vielleicht vom 2. mal abgesehen – nur voll und ganz zustimmen, aber einen 8. Punkt möchte ich aber gerne selber noch hinzufügen:

8. Bei Codeaktualisierungen auch die Kommentare aktualisieren
Ich möchte nicht darauf rumreiten, dass man seinen Code auch kommentieren sollte. Aber eine Sache ist im Zusammenhang mit Kommentaren im Code extrem wichtig: Wenn es bereits Kommentare gibt und man aktualisiert den Code zu diesen Kommentaren, dann sollte man sich auch mal genau ansehen, ob die Kommentare noch stimmen. Denn ich finde falsche Kommentare eigentlich noch schlimmer als gar keine Kommentare, da man dadurch unter Umständen den Code völlig fehlinterpretiert.

Auf jeden Fall kann es nicht schaden, sich den Artikel mal durchzulesen. Ich empfehle auch die Kommentare zu beachten, da dort interessante Aspekte diskutiert werden.