Die flinke Feder

Ode an die IDE

Bernd Fondermann

Das Maß für die Produktivität einer Programmiersprache ist oftmals nicht die Anzahl der Sprachfeatures, sondern die Anzahl der Zeichen, die benötigt wird, um „Hello World!“ auszugeben oder die Türme von Hanoi umzuschichten. Das ist eine sehr gültige Herangehensweise. In der Kürze liegt ja bekanntlich die Würze. Man schreibt also für den direkten Vergleich denselben Algorithmus in beiden Sprachen auf, hält den Code nebeneinander und zählt. Bestimmte Sprachen stehen hier auf der Gewinnerseite: Lisp, JavaScript, Ruby, Perl und auch Scala. Alle haben ein hohes Signal-Noise-Verhältnis: Mit wenig Zeichen wird viel Programm ausgedrückt. Java selbst und auch C++ gehören nicht dazu.

Ein praxisnahes Beispiel: Um eine Liste von Strings zu deklarieren und (leer) zu initialisieren, braucht es in Java schon 44 Anschläge für 40 Nicht-Leerzeichen (etwaige Einrückungen nicht mitgezählt): List<String> list = new ArrayList<String> ();. Und befüllt ist die Datenstruktur damit ja noch gar nicht. Mit den Java-Sprachrevisionen hat das Iterieren über unsere Map durch Einführung von Iteratoren und der verkürzten For-Schleife schon zwei Diäten hinter sich gebracht und steht nun in der hier gezeigten Version mit Ausgabe über System.out bei 44 Anschlägen (inklusive zwei Zeilenumbrüche, also 38 Zeichen):

for (item: list) {
    System.out.println(item);
}

Dieser Logik und dem Wunsch nach höherer Produktivität folgend, habe ich schon mehr als einmal den Weg zu Ruby und Scala gesucht. In Ruby [1] beispielsweise ist die Listendeklaration unschlagbar kurz: list = [].Allerdings wird hier nicht ausgedrückt, welche Typen sie enthalten soll. Eine Iteration lässt sich ebenfalls recht knackig ausdrücken (mit 30 Anschlägen, also rund zwei Drittel des Java-Bedarfs):

    list.each {
        |item| puts item
    }

Von meinen Ausflügen zu anderen Sprachen bin ich – Überraschung oder nicht – jedes Mal nach kurzer Zeit zurück zu Java gewechselt. Dafür gibt es zwei Gründe: Der erste ist, dass ich offensichtlich das „streng typisiert“-Gen in mir trage. Oder andersrum: Ich habe einfach keine Schwäche für schwache Typen. Womit dann Ruby und Perl schon schlechte Karten haben. Der zweite Grund ist aber viel gravierender: Die Metrik stimmt nicht. Die Berechnung ist falsch. Ich brauche gar nicht all diese Zeichen zum Tippen, sondern weniger, teilweise dramatisch viel weniger. Wie kommt das?

Es liegt am Werkzeug, an der IDE, der integrierten Entwicklungsumgebung meiner Wahl. Ich nutze beispielsweise Intellijs IDEA [2], viele andere nutzen Eclipse [3], manche nutzen das von mir noch nie verwendete NetBeans [4]. Und die in diesen Umgebungen enthaltenen Editoren laufen auf Steroiden, wenn man sie richtig einsetzt. Zurück zum Beispiel der Listendeklaration: 23 Tasten, inklusive Shortcuts muss ich nur drücken, also rund die Hälfte des Brutto-Java-Codes. Ähnlich effizient ist die Iteration: Iterator-Kürzel eingeben und schon steht der Rumpf vor mir. Einige Lücken wie Variablennamen müssen noch gefüllt werden, aber oft passt da schon die Vorbelegung der IDE – 23 Anschläge.

Im Großen und Ganzen gilt: Je mehr Informationen, vor allem Typinformationen, die IDE vorfindet, desto bessere Unterstützung kann sie leisten. Mit dem Vorschlagswesen von Methodennamen anhand der Klasse der Variable fing es an. Das konnten spätestens die IDEs der Neunziger Jahre. Mittlerweile kann die IDE im günstigen Fall komplette Parameterlisten mit Variablen aus dem Scope vorbelegen, da es Typen und Variablennamen in die Vorhersageheuristik mit einbezieht. Auch viele kleine und große Refactorings sind möglich, die manche Nutzer oftmals noch gar nicht entdeckt haben.

Abb. 1: IDE-Vorschlag „Bring . into Scope“

Hat man beispielsweise eine Variable im try-Block deklariert, befindet sich aber nun im catch-Block und möchte darauf zugreifen, so hilft ein Aufruf des schnellen Helfer-Shortcuts (CTRL-1 in Eclipse, ALT-RETURN in IDEA), der einem ein „Bring … into Scope“ vorschlägt (Abb. 1). Mit einem schnellen Druck auf die RETURN-Taste und ohne mich von meiner aktuellen Cursor-Position wegzubewegen, ist die Variable wie von Geisterhand nun außerhalb des Try-Catch deklariert, inklusive Initialisierung. Voilà! So geht es auch mit komplexen Änderungen von Methodensignaturen, wobei auch alle entsprechenden Aufrufe angepasst werden. Gleiches gilt für throws-Deklarationen, Umbenennungen, Typänderungen, Entfernen von final-Deklarationen bei Neuzuweisung, Einfügen von Imports etc.

IDEs haben aber noch mehr auf Lager: Sie sind SQL-Clients, validieren und erzeugen DTDs und WSDLs, committen, mergen und führen darüber hinaus noch eine lokale Historie aller Edit-Operationen. Eine ihrer Spezialitäten ist der schnelle Zugriff auf jegliche Datei im Projekt anhand von Namen oder Inhalt. Unverzichtbar ist der unmittelbare Sprung zu allen Aufrufern einer Methode oder Verwendungen einer Konstante.

Fakt ist, meine IDE ist das wichtigste Produktivitätswerkzeug, das ich habe. Abschließend sei noch der Hinweis erlaubt, dass Intellij IDEA, Eclipse und NetBeans allesamt auch als Umsonst-Open-Source zur Verfügung stehen. Erforschen Sie doch mal Ihre IDE, Sie werden garantiert Produktivitätssteigerndes entdecken!

Bernd Fondermann (bernd[at]zillion-one.com) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt a. M. und Member der Apache Software Foundation. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop oder Lucene und bietet unter zillion-one.com einen Big-Data-Hosting-Service an.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.