Neues bei den Refactorings

Refactoring, entstanden eigentlich im Kontext agiler Software-Entwicklung, hat sich mittlerweile zu einer Standardtechnik entwickelt, die heutzutage jeder Software-Entwickler beherrschen sollte. Mit dem sogenannten „Eclipse Way“ setzen die JDT-Entwickler darüber hinaus ihren eigenen agilen Entwicklungsprozess um und führen bei der täglichen Entwicklungsarbeit vermutlich sehr häufig selbst Refactorings durch. Nur so lässt sich erklären, dass Eclipse eine solch solide Unterstützung für Refactoring im Angebot hat. Und natürlich hat sich in diesem Jahr auch wieder etwas in diesem Bereich getan, zum Beispiel im Refactoring EXTRACT METHOD. Mit dieser hilfreichen Funktion ist man in der Lage, unübersichtliche Stellen im Quelltext auseinanderzuziehen und bestimmte Teile in separate Methoden auszugliedern. Ab sofort kann dieses Refactoring auch mit Quellcode umgehen, welcher den Befehl continue enthält. Wichtig dabei ist nur, dass vor dem Ausführen dieses Refactorings nicht nur der Block mit dem continue-Befehl selbst markiert wurde, sondern auch noch die folgende Zeile/Anweisung. Andernfalls hat JDT wenig Chancen, eine sinnvolle Methode daraus zu generieren (Abb. 3).

In der gleichen Funktion haben die Entwickler außerdem noch eine Plausibilitätsprüfung eingebaut. Dies bedeutet, wenn man versucht EXTRACT METHOD auf einen Code-Block auszuführen, der mehrere Zuweisungen auf unterschiedliche Variablen enthält, zeigt Eclipse nun eine Liste aller Variablen an, die in Konflikt zueinander stehen und aufgrund dessen das Extrahieren in eine neue Methode nicht möglich ist.

Lange an Bord ist auch schon das Refactoring CONVERT MEMBER TYPE TO TOP LEVEL. Mit diesem Refactoring war man in der Lage, Inner Classes in eigene Dateien auszulagern. Hierzu musste lediglich im Java-Editor der Cursor in die entsprechende Inner Class platziert und die genannte Refactoring-Funktion ausgewählt werden. Für die gewählte Inner Class wurde dann eine eigene Datei im gleichen Package und Ordner angelegt und automatisch auch alle Referenzen angepasst. Dieses Refactoring ist im Helios-Release nach wie enthalten, wurde jedoch in MOVE TYPE TO NEW FILE umbenannt. Das Refactoring kann neben Inner Classes nun auch eingesetzt werden, wenn man in einer .java-Datei neben der Hauptklasse noch sekundäre Klassendefinitionen hat (dürfen weder private noch public deklariert sein!) und man diese nun sauber in separate Java-Quellcodedateien auslagern will.

Nice-to-have

Und wie jedes Jahr, finden sich natürlich auch im diesjährigen JDT-Release wieder einige kleine Erweiterungen und Verbesserungen, die das Entwickler-Leben angenehmer machen. Ein paar von diesen „Nice-to-have’s“ sollen im Folgenden dargestellt werden.

So finden sich für den Bereich automatische Quellcodeformatierung in den Preferences unter JAVA | CODE STYLE | FORMATTER im Reiter LINE WRAPPING recht interessante neue Optionen, um den Zeilenumbruch im Quelltext zu beeinflussen. Es kann beispielsweise eingestellt werden, dass beim Einsatz von Annotationen mit Attributen jedes Attribut in einer eigenen Zeile stehen soll. Auf der gleichen Seite kann außerdem (optional) eingestellt werden, ob in einer Methoden-Deklaration Modifier, Rückgabewert und Name der Methode in jeweils eigenen Zeilen stehen sollen.

Ganz neu hingekommen ist der Reiter ON/OFF TAGS auf gleicher Ebene wie LINE WRAPPING. Mit dieser neuen Funktion können Start- und Ende-Tags definiert werden, die man als Kommentar in den Quelltext einstreuen kann, um festzulegen, welche Bereiche des Quellcodes vom Eclipse Formatter berücksichtig werden soll und welche nicht. In der Standardeinstellung ist diese Funktion deaktivert, außerdem ist „@formatter:on“ als Start-Tag und „@formatter:off“ als End-Tag voreingestellt. Die Bezeichnungen dieser Tags können jedoch frei festgelegt werden. Sind die On/Off-Tags aktiviert, kann man nun bestimmen, für welche Bereiche des Quelltexts der automatische Code Formatter von Eclipse aktiv werden soll, in dem man die Tags als Kommentare in den Quelltext schreibt. Dabei ist es wichtig zu verstehen, dass zu Beginn die Automatikformatierung immer angeschaltet ist. Will man also schon von der ersten Zeile ab einen bestimmten Bereich vom Code Formatter ausschließen, so muss direkt in der ersten Zeile der entsprechende Off-Tag in einem Kommentar eingefügt werden. Das An- bzw. Abschalten des Code Formatter wird jeweils nach der Kommentarzeile mit Tag aktiv. Abbildung 4 zeigt ein Beispiel: In den ersten Zeile ist die automatische Formatierung noch aktiv, erst mit Beginn der Methode foo() wird die automatische Formatierung mit Hilfe des Off-Tags abgeschaltet.