In letzter Zeit habe ich in mehreren verschiedenen Teams festgestellt, dass ihre Coding-Standards bei der Verwendung von Leerzeichen stark variieren. Das hat meine Neugier geweckt, denn ich hatte immer gedacht, dass es eine allgemein anerkannte Best Practice für die Verwendung von Leerzeichen bei der Codeformatierung geben sollte. Doch in der realen Entwicklung scheint sich eine solche Einheitlichkeit nicht herausgebildet zu haben.

Aktueller Stand

Schauen wir uns zunächst die Stilkonventionen für Java-Code in den meisten Java-IDEs an.

Hier ist ein Beispiel:

public class Example {

public static void main(String[] args) {
    int answer = 2 + 4 * 6;
    for (int i = 0; i < 5; i++) {
        doSomething();
    }
    System.out.println("The answer is " + answer);
}

    private static void doSomething() {
        // something
    }
}

Beachten Sie, dass dies der am weitesten verbreitete Stil unter Java-Programmierern und in anderen C-ähnlichen Sprachen ist.

In den Klammern befinden sich auf keiner Seite Leerzeichen. Nur wenn der Klammer ein Schlüsselwort wie 'for' oder 'while' vorausgeht, erscheint ein Leerzeichen zwischen ihnen, aber zwischen einem Methodennamen und der folgenden Klammer steht kein Leerzeichen. Vor der öffnenden geschweiften Klammer (die normalerweise am Zeilenende steht) steht jedoch immer ein Leerzeichen. Mathematische Operatoren sind immer von Leerzeichen umgeben. Und vor einem Semikolon steht kein Leerzeichen.

Wenn Sie oft Code lesen, halten Sie dies vielleicht für eine sehr natürliche Anordnung, aber wenn Sie kein Programmierer sind, könnten Ihnen diese Regeln zu willkürlich erscheinen, mit vielen Inkonsistenzen, Sonderfällen und diskussionswürdigen Punkten.

Bitte lassen Sie mehr Platz für Ihren Code

In meinem aktuellen Entwicklungsprojekt gibt es zwei Hauptentwicklungsteams im Unternehmen: eines ist das Team Load Test Products (LTP), und das andere ist das Team Functional Test Products (FTP). Beide Teams befolgen bestimmte Konventionen für den Programmierstil, und beide sind besonders großzügig im Umgang mit Leerzeichen, wie im folgenden Beispiel für ein Code-Snippet:

public class Example
{

    public static void main( String[] args )
    {
        int answer = 2 + 4 * 6;
        for( int i = 0; i < 5; i++ )
        {
            doSomething();
        }
        System.out.println( "The answer is " + answer );
    }

    private static void doSomething()
    {
        // something
    }

}

Dieser Stil lässt den Code weniger dicht und gleichmäßiger erscheinen (zum Beispiel steht vor öffnenden Klammern kein Leerzeichen, und auf der inneren linken und rechten Seite aller runden Klammern, geschweiften Klammern und eckigen Klammern stehen Leerzeichen)! Ich sage nicht, dass dies besser oder schlechter als der vorherige Stil ist ... er macht es nur einfacher, Wörter zu unterscheiden. Der Preis dafür ist, dass ein einzelner Bildschirm weniger Code anzeigen kann.

Obwohl jeder Coding-Stil seine eigenen Vor- und Nachteile hat, hat es mich überrascht, dass das FTP-Entwicklungsteam sich schließlich entschied, zum zuvor erwähnten gebräuchlichsten Coding-Stil zu wechseln. Sie hielten die Änderung für lohnenswert, und sie haben sogar darüber diskutiert, also glaube ich, dass sie die Änderung für wichtig hielten. Ihre Entscheidung basierte nicht darauf, ob dieser Stil besser ist als jener ... Ich denke, sie konzentrierte sich hauptsächlich darauf, wer an diesen Stil gewöhnt ist, da die meisten unserer Produkte Open Source sind, was ein wichtiger Grund ist: Es erleichtert Programmierern in der Community, Code beizutragen.

In meinem Team, dem LTP-Team, halten wir weiterhin an unserem Stil fest und haben nicht die Absicht, irgendetwas zu ändern. Zumindest für mich ist dies eine Entscheidung, die auf technischen Überlegungen beruht: Wenn ein anderer Coding-Stil keinen Vorteil zeigt (unser Projekt hat kaum Bedarf an Open-Source-Beiträgen), warum zu einem anderen Stil wechseln?

Regeln müssen vereinheitlicht werden

Ich habe Code zu Open-Source-Projekten beigetragen, wie etwa der Programmiersprache Ceylon, und war sehr überrascht, dass sie überhaupt keinem Coding-Stil folgen. Man kann Code in jedem beliebigen Stil schreiben.

Einige Programmierer, die von der schieren Menge an Coding-Standards in manchen Unternehmen eingeschüchtert wurden, mögen das vielleicht, aber ich glaube, dass der Code Ihres Projekts ohne eine Reihe von Coding-Standards wahrscheinlich im Formatierungschaos endet. Jeder Code-Beitragende bringt beim Einreichen von Code seinen oder ihren eigenen einzigartigen Code-Stil mit, was nicht überraschend ist; das Ergebnis ist, dass der gesamte Code uneinheitlich ist, und Sie können in den wenigen unten stehenden Codezeilen mehrere verschiedene Stile sehen:

while (exists cell = iter) {
        if (exists elem = cell.element,
        elem==element) {
            last = cell;
        }
        iter = cell.rest;
    }
}

if (exists cell=last){
    cell.element=replacement;
    return true;
}
assert (0<=index<length);

Die Hauptfrage, die ich aufwerfen möchte, ist: Ist Coding-Stil wirklich eine wichtige Entwicklungspraxis? Wie stark wirkt er sich auf die Effizienz von Programmierern bei der Softwareentwicklung aus?

Ich glaube, diese Frage hängt mit einer anderen ähnlichen Frage zusammen: Beeinflusst die Codeformatierung die Lesbarkeit des Codes?

Codeformatierung beeinflusst die Lesbarkeit des Codes

Ich denke, diese Frage ist sehr leicht zu beantworten! Natürlich tut es das. Scannen Sie die folgenden zwei Codeausschnitte Zeile für Zeile (aus dem Ceylon-Projekt), und Sie werden leicht spüren, welcher leichter zu lesen ist. – CeylonCreate)?

function validModuleNameChar(Character c)=>c.letter||c.digit||c in ['_','.' ];
if (!trimmedName.empty,
    validModuleNameFirstChar(trimmedName.first else 'X'),
    trimmedName.every(validModuleNameChar),
    !(trimmedName.split('.'.equals,true,false)).containsAny(ceylonKeywords.chain {""})) {
    return trimmedName;
}
function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

Der Unterschied mag klein sein, aber wenn Sie den ganzen Tag viel Zeit mit dem Lesen von viel Code verbringen, wird der Unterschied riesig.

Lektionen aus dem gewöhnlichen Schreiben von Text

Wenn wir über die Lesbarkeit von Code sprechen, sollten wir vielleicht einen Blick auf die gewöhnlichere Fähigkeit der Menschen werfen, Text zu lesen. Diese Fähigkeit hat sich über Tausende von Jahren entwickelt, also hätte eine bessere Lösung gefunden worden sein müssen!?

Im 'gewöhnlichen' Englisch sieht man die übliche Verwendung von Leerzeichen, aber man sieht keine Autoren darüber diskutieren, ob sie Leerzeichen um Klammern herum verwenden sollten! Wie würde es also aussehen, wenn Code wie 'gewöhnliches' Englisch geschrieben würde?

Kehren wir zum einfachen Beispiel oben zurück:

function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

Die meisten Dinge im Code sind wie in gewöhnlichen englischen Sätzen. Man verwendet Klammern, um bestimmte Wörter zu 'gruppieren'. Man verwendet Leerzeichen zwischen Wörtern und Symbolen – hier finden wir einen Ort, der von üblichen Programmiergewohnheiten abweicht: Wenn wir eine Methode aufrufen, steht kein Leerzeichen zwischen dem Methodennamen und der folgenden Klammer, und nach dem Punktoperator wird kein Leerzeichen gelassen.

Ich kann verstehen, warum an diesen Stellen keine Leerzeichen sind, weil diese Klammern oder Punkte im Code eine Art 'Besitz'-Beziehung oder eine Assoziation darstellen. Aber ist es wirklich notwendig, dieses bisschen Platz herauszupressen, um diese Beziehung darzustellen? Fühlt es sich nicht sehr klar an, wenn wir uns den Beispielcode oben ansehen?

Eine weitere Sache, die im gewöhnlichen Englisch nicht existiert, sind verschachtelte Ausdrücke ... Wir haben also Situationen, die im gewöhnlichen englischen Schreiben nicht vorkommen. Aber das ist kein großes Problem; wir müssen uns nur eine allgemeine Regel merken: Fügen Sie auf beiden Seiten von Symbolen Leerzeichen hinzu.

Finden Sie, dass der Code oben etwas seltsam aussieht? Ich muss zugeben, er wirkt ein wenig ungewohnt, aber ich glaube, das liegt nur daran, dass ich mich noch nicht daran gewöhnt habe.

Obwohl ich mich noch nicht daran gewöhnt habe, bin ich sicher, dass dieser Code leichter zu lesen und zu verstehen ist.

Ich kann klar sagen, dass wir Programmierer das Lesen von Code viel einfacher finden würden, wenn der gesamte Code solchen Konventionen folgen würde.

Fazit

Ich hoffe, kein Programmierer würde denken, dass das Befolgen eines vordefinierten Codierungsstandards das Programmieren schwieriger macht!

Zunächst einmal können alle IDEs so konfiguriert werden, dass sie die Codeformatierung automatisch anpassen. Du kannst Code unordentlich schreiben, aber vergiss am Ende nicht, vor dem Commit die Tastenkürzel der IDE zu verwenden, um den Code aufzuräumen. Ähnlich bezweifle ich, dass ein Autor denken würde, die Formatierungsregeln für das Schreiben von Text seien zu streng und würden seine Kreativität einschränken.

Glücklicherweise stelle ich fest, dass es bei der Verwendung von Leerzeichen in allen aktuellen Codierungsstilen und -standards keine größeren Probleme gibt. Aber etwas mehr Leerzeichen zu verwenden, wird den Code definitiv klarer und leichter lesbar machen.

Originaltext:Gib deinem Code etwas Platz!

Quelle:Ausländische IT-Review