Refactoring-Tipp: Variablen umbenennen

Bekanntlich wird die Code-Qualität in der Einheit WTFs/min gemessen (WTF = What the f**k). Lassen Sie einen fremden Entwickler Ihren Quellcode lesen und zählen Sie die minütlichen WTFs, die diese Person ausspricht.

Diese WTFs werden ausgesprochen, weil der fremde Entwickler den Quellcode nicht versteht und nicht nachvollziehen kann. Er liest ihn und wird ständig durch Unklarheiten aus dem Fluss gerissen.

Ungünstige Variablen-Namen

Das folgende Beispiel verdeutlicht, was ungünstige Variablen-Namen verursachen können:

public void printDocument(Document d) {
  final int m = 75;
  final String c = '...';
  String value = d.getContent();

  if (value.length > m) {
    String value = value.substring(0, m) + c;
  }

  System.out.print(value);
}

Können Sie nachvollziehen, was in dem o.a. Quellcode passiert?

Ein möglicher Lesefluss könnte wie folgt aussehen:

1. „Die Methode heißt printDocument und wird somit vermutlich das Dokument ausgeben oder ausdrucken.“
2. „Ok, es gibt zwei Konstanten ‚m‘ und ‚c‘. Mal schauen, wofür die benötigt werden.“
3. „Nun wird die Variable ‚value‘ befüllt. Der Inhalt statt aus der dem Objekt ‚d‘. Was ist ‚d‘ nochmal? [Blick wandert nach oben] Achja, das ist ja das Dokument“
4. „Nun wird geprüft, ob die Länge des Dokumentes größer als ‚m‘ ist. Was ist ‚m‘ nochmal? [Blick wandert nach oben] Achja, ‚m‘ hat den Wert 75. Keine Ahnung, was das bedeutet…“
5. „Achso, nun wird das Dokument auf auf 75 Zeichen beschnitten. ‚m‘ scheint also die maximale Länge zu sein. Und warum wird dort nun ‚c‘ angehängt? [Blick wandert nach oben] Achja, das sind die 3 Punkte, um zu signalisieren, dass der String abgeschnitten wurde.“

Solche Quellcodes sind in älterer Software oft anzutreffen. Sie stammen ggf. noch aus Zeiten, in denen die Länge von Variablenbezeichnern begrenzt waren. Durch einfache Refactoringmaßnahmen können sie jedoch vereinfacht werden.

Die Variablen umbenennen

Bevor Änderungen an solchen Quelltexten vorgenommen werden, sollten die Variablen entsprechend umbenannt werden. Dadurch erhöht sich die Lesbarkeit und die Verständlichkeit des Quellcodes, sodass die geplanten Änderungen einfacher und weniger fehlerbehaftet durchgeführt werden können.

In dem folgenden Beispiel wurden die Variablen „d“, „m“, „c“ und „value“ umbenannt, um das Verständnis zu erhöhen, dass z.B. der Wert „75“ die maximale Länge des Dokumenten-Inhaltes angibt.

public void printDocument(Document document) {
  final int MAX_LENGTH = 75;
  final String CUTTING_SUFFIX = '...';
  String documentContent = document.getContent();

  if (documentContent.length > MAX_LENGTH) {
    documentContent = documentContent.substring(0, MAX_LENGTH) + CUTTING_SUFFIX;
  }

  System.out.print(documentContent);
}

An dieser Stelle wird explizit nur eine Variablenumbenennung durchgeführt. Weitere Refaktorisierungen können bei Bedarf im Anschluss durchgeführt werden.

Unterstützung durch die Entwicklungsumgebung (IDE)

Moderne Entwicklungsumgebungen unterstützen sehr gut bei solchen Refaktorisierungen. Die Variablenumbenennung ist z.B. bei IntelliJ IDEA, PhpStorm, WebStorm und weiteren JetBrains IDEs über das Kontext-Menü unter „Refactor“ > „Rename“ durchführbar. Die IDE übernimmt dann die Umbenennung der Variable sowie aller dazugehöriger Referenzen.

Einsatz der Pfadfinder-Regel

Bei diesem Refactoring-Tipp geht es nicht um umfangreiche Refaktorisierungen. Es geht darum, dass bereits kleine Anpassungen einen großen Mehrwert erzeugen können. Führt ein Entwickler jeweils die einfachen Refaktorisierungen an dem anzupassenden Quelltext durch, so wird der Quelltext Schritt für Schritt besser. Die sog. Pfadfinder-Regel ist eine gute Möglichkeit, um dieses Vorgehen im Entwicklungs-Team zu etablieren:
Die Pfadfinder-Regel besagt, dass der Quellcode immer sauberer hinterlassen werden soll, als er aufgefunden wurde. Arbeitet ein Entwickler an einem Quelltext, sollte er diesen somit sauberer hinterlassen. Dies kann u.a. durch die in diesem Artikel behandelte Variablenumbenennung erfolgen.