icancode.de

Java im Abseits

Einleitung

Rico Magnucki

Rico Magnucki

21st Century Digital Boy und Blog-Gründer. Studiert naturwissenschaftliche Informatik in Bielefeld. Auf dem Blog ist er der Ansprechpartner für LaTeX, schreibt Tutorials, dreht die Videos für YouTube und durchforstet das Internetz nach spannenden Dingen.


Neuste Artikel

HP Deskjet 3636 – Multitalent zum schmalen Preis 09th April, 2017

NETGEAR AC1750 Smart WLAN-Router im Test 10th January, 2016

Internet

Java im Abseits

Veröffentlicht am .

Seit einiger Zeit macht auf Twitter ein Tweet die Runde, der Java-Code in einer ziemlich kuriosen Formatierung zeigt. Alle Klammern und Semikolons sind an den Rand gerutscht, wodurch der Code nun fast wie der von Python aussieht.

Übersetzung:

»Ich habe endlich herausgefunden, wie ich diese nervtötenden Semikolons und geschweiften Klammern aus meinem Java-Code bekomme.«

Python oder doch Java?

Auch wenn der Tweet ziemlich sicher nicht ernst gemeint ist, gucken wir uns mal die Machbarkeit an.

Der Übersicht halber, habe ich den Code nochmal ordentlich aufgeschrieben. So sieht der Code aus, wird er von einem üblichen Formater – wie er in IntelliJ IDEA oder Eclipse zu finden ist – formatiert und so kennen wir ihn.  Wie bei so ziemlich allen Sprachen, die bei der Bildung von Blöcken auf Klammern setzen, haben wir hier einige Zeilen, die nur aus Klammern bestehen und den Code somit (unnötig) in die Länge ziehen.

[annotated header=“Übliche Formatierung“ annotation=“16 Zeilen Code“]


    public class Permuter {
        private static void permute (int n, char[] a) {
            if (n == 0) {
                System.out.println(String.valueOf(a));
            } else {
                for (int i = 0; i <= n; i++) {
                    permute(n - 1, a);
                    swap(a, n % 2 == 0 ? i : 0, n);
                }
            }
        }
        
        private static void swap (char[] a, int i, int j) {
            char saved = a[i];
            a[i] = a[j];
            a[j] = saved;
        }
    }
    

[/annotated]
Der Code, den wir in dem Tweet sehen sieht gänzlich anders aus. Er bedient sich den Formatierungsprinzipien der sog. off-side rule (Abseitsregel), welche Beispielsweise von Python oder Haskell verwendet wird. Hierbei wird die Gruppierung von Code nicht durch Klammern gekennzeichnet, sondern durch die Einrückung. Der Code ist also auf verschiedenen Ebenen organisiert, basierend auf der Einrücktiefe.  Dadurch schrumpft die Anzahl der Zeilen von 16 auf 11. Je länger ich mir diese neue Formatierung ansehe, umso besser finde ich sie. Jedenfalls im Bezug auf die Lesbarkeit.

[annotated header=“Neue Formatierung“ annotation=“11 Zeilen Code“]


    public class Permuter                                             {
        private static void permute (int n, char[] a)                 {
            if (n == 0)                                               {
                System.out.println(String.valueOf(a))                 ;}
            else                                                      {
                for (int i = 0; i <= n; i++)                          {
                    permute(n - 1, a)                                 ;
                    swap(a, n % 2 == 0 ? i : 0, n)                    ;}}}

        private static void swap (char[] a, int i, int j)             {
            char saved = a[i]                                         ;
            a[i] = a[j]                                               ;
            a[j] = saved                                              ;}}
    

[/annotated]

Alltagstauglich oder nicht?

Neue Ideen hin oder her, die viel wichtigere Frage ist doch eigentlich, ob sie in der Praxis nutzbar ist. Die Antwort ist ganz klar: JEIN

Anders als bei Sprachen mit einer echten off-side rule ist die Formatierung hier nur eine optische Entscheidung, die keinerlei Logikänderungen mit sich zieht. Eben da kann es aber gefährlich werden, wenn die Formatierung nicht zu 100 % eingehalten wird. Die Verständlichkeit ist nicht mehr gegeben, was zu großer Verwirrung führen kann.

Wie so häufig kommt es auch ganz klar auf die Art des Projekts und das Team an. Schreibe ich an dem Projekt alleine, kann mich auch keiner daran hindern, diese Formatierung zu verwenden. Handelt es sich um ein größeres Projekt mit vielen Beteiligten, Qualitätssicherung und Co. dann wird das schon ziemlich schwierig. Aber auch hier besteht die Möglichkeit die Formatierung zu nutzen, vorausgesetzt, dass alle Beteiligten damit einverstanden sind. Im Optimalfall ist dann natürlich eine Konfiguration für den Formater der IDE eurer Wahl verfügbar, um eventuelle Komplikationen zu vermeiden.

Rico Magnucki

Rico Magnucki

http://magnucki.de

21st Century Digital Boy und Blog-Gründer. Studiert naturwissenschaftliche Informatik in Bielefeld. Auf dem Blog ist er der Ansprechpartner für LaTeX, schreibt Tutorials, dreht die Videos für YouTube und durchforstet das Internetz nach spannenden Dingen.

Navigation