In der Diskussion über die Platzierung von geschweiften Klammern wurden bereits einige Anmerkungen zum Leerraum gemacht.

Ich selbst neige dazu, meinen Code mit Leerzeilen zu bestreuen, um Dinge, die in "logischen" Gruppen zusammengefasst sind, voneinander zu trennen und hoffentlich der nächsten Person das Lesen des gerade erstellten Codes zu erleichtern.

In der Tat würde ich sagen, dass ich meinen Code so strukturiere, wie ich ihn schreibe: Ich mache Absätze, die nicht länger als ein paar Zeilen sind (definitiv kürzer als 10), und versuche, jeden Absatz in sich geschlossen zu machen.

Beispielsweise:

• In einer Klasse werde ich Methoden gruppieren, die zusammengehören, während ich sie durch eine Leerzeile von der nächsten Gruppe trenne.
• Wenn ich einen Kommentar schreiben muss, setze ich normalerweise eine Leerzeile vor den Kommentar
• In einer Methode mache ich einen Absatz pro Schritt des Prozesses

Alles in allem habe ich selten mehr als 4/5 Zeilen zusammengefasst, was einen sehr spärlichen Code bedeutet.

Ich betrachte all diesen Leerraum nicht als Verschwendung, da ich ihn tatsächlich zum Strukturieren des Codes verwende (da ich den Einzug tatsächlich verwende), und daher denke ich, dass er den erforderlichen Bildschirmplatz wert ist.

Beispielsweise:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Ich bin der Meinung, dass die beiden Aussagen eindeutige unterschiedliche Zwecke haben und daher eine Trennung verdienen, um dies deutlich zu machen.

Also, wie benutzt man eigentlich (oder nicht) Leerzeilen im Code?

Immer

Leerzeichen sind für die Bereinigung von lesbarem Code von entscheidender Bedeutung. Durch eine leere Zeile (oder zwei) können logische Codeblöcke visuell voneinander getrennt werden.

Zum Beispiel aus Steve McConnells Kapitel Code Complete, Second Edition, über Layout und Stil:

Die Testpersonen erzielten bei einem Test des Verständnisses 20 bis 30 Prozent mehr Punkte, wenn die Programme ein Einrückschema mit zwei bis vier Stellen aufwiesen, als wenn die Programme überhaupt keine Einrückung aufwiesen.Dieselbe Studie ergab, dass es wichtig ist, die logische Struktur eines Programms weder zu stark noch zu stark zu betonen. Die niedrigsten Verständlichkeitswerte wurden für Programme erzielt, die überhaupt nicht eingerückt waren. Das zweitniedrigste Ergebnis wurde bei Programmen erzielt, bei denen Einrückungen mit sechs Leerzeichen verwendet wurden. Die Studie kam zu dem Schluss, dass die Einrückung mit zwei bis vier Abständen optimal war. Interessanterweise waren viele Versuchspersonen der Meinung, dass die Einrückung mit sechs Stellen einfacher zu verwenden ist als die kleineren Einrückungen, obwohl ihre Punktzahlen niedriger waren. Das liegt wahrscheinlich daran, dass die Einrückung mit sechs Leerzeichen angenehm aussieht. Unabhängig davon, wie hübsch es aussieht, sind Einrückungen mit sechs Stellen weniger lesbar. Dies ist ein Beispiel für eine Kollision zwischen Ästhetik und Lesbarkeit.

Ja zur Klarheit.

Genau wie ich es in dieser Antwort getan habe.

Ich mache es, aber ich stelle sicher, dass ich es dokumentiere, indem ich es setze

(This line intentionally left blank.)

an der Leitung

Ja, aber ich missbrauche es nicht.

Ich habe Code gesehen, bei dem jede Codezeile in einer Methode durch eine Leerzeile getrennt ist und zwei Leerzeilen verwendet werden, wenn eine logische Trennung auftritt. Das macht es meiner Meinung nach nur noch weniger lesbar. Ich habe auch Leerzeichen gesehen, mit denen verrückte Ausrichtungen vorgenommen wurden, wie zum Beispiel:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

Der gleiche Missbrauch von horizontalen Leerzeichen kann auf vertikale Leerzeichen angewendet werden. Verwenden Sie es wie jedes Werkzeug mit Bedacht.

Ich werde oft dafür kritisiert, dass ich meinen Code auf diese Weise schreibe. Ich verstehe nicht, warum jemand es nicht so machen würde.

Lesbarkeit ist so wichtig, wenn Sie nach einer längeren Zeit zu einem Projekt zurückkehren und ich den Spruch "Schreiben Sie immer Code, wenn der nächste Typ, der es liest, ein Psychopath ist, der Ihren Standort kennt" gehört habe.

Ich schreibe nicht immer Software, aber wenn ich das tue, verwende ich aus Gründen der Klarheit leere Zeilen.

Ich bin alles dafür, Code so klar wie möglich zu gestalten, und Leerzeichen sind oft ein nützliches Werkzeug für diese Bemühungen. Vergessen wir aber nicht das Refactoring:

• In einer Klasse werde ich Methoden gruppieren, die zusammengehören, während ich sie durch eine Leerzeile von der nächsten Gruppe trenne.

Da Sie mehrere verwandte Mitglieder haben, sind diese Kandidaten für eine neue Klasse.

• Wenn ich einen Kommentar schreiben muss, setze ich normalerweise eine Leerzeile vor den Kommentar

Wenn der Code unklar genug ist, um einen Kommentar zu wünschen, frage ich, ob ich den Code so umgestalten kann, dass er klar genug ist, um den Kommentar nicht zu benötigen.

• In einer Methode mache ich einen Absatz pro Schritt des Prozesses

Warum nicht eine Methode für jeden "Absatz" erstellen?

Wenn Sie am Ende eine Reihe von Methoden in Ihrer Klasse haben, lesen Sie den obigen Hinweis zum Extrahieren einer neuen Klasse.

Ja. Dies erleichtert das visuelle Scannen einer Datei. Unter anderem wird dadurch klarer, zu welcher Zeile ein Kommentar gehört.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

Ich benutze leere Zeilen sparsam und konsequent und ist konsequent wichtiger als sparsam. Jedoch:

• Wenn jede Codezeile durch eine Leerzeile von der nächsten getrennt ist, sind zu viele Leerzeilen vorhanden.
• Wenn es weder einen Reim noch einen Grund gibt, der leicht erkennbar ist, wo leere Linien platziert werden, dann sind sie eine Ablenkung und es gibt gewöhnlich zu viele von ihnen.
• Wenn eine Funktion so groß ist, dass sie viele Leerzeilen benötigt, ist sie zu groß.
• Wenn ein Codeblock davor oder danach mehr als eine Leerzeile benötigt, liegt etwas ernsthaft in die Irre.
• Wenn Sie mehr als zwei Leerzeilen zwischen Funktionen haben, haben Sie wahrscheinlich zu viele Leerzeilen.

Das meiste davon ist nicht schrecklich umstritten; was folgt könnte sein. Ich stelle fest, dass nach der K & R-Notation mit den offenen Klammern am Zeilenende oft eine Leerzeile folgt. Ich persönlich mag die geschweiften Klammern am Ende der Zeile nicht und das Mischen mit einer Leerzeile nach der geschweiften Klammer macht einen Unsinn in der Notation (IMNSHO). Setzen Sie die offene Klammer in die nächste Zeile, und Sie haben eine meist leere Zeile (und, IMNSHO, besser lesbaren Code). Wenn Sie am Ende der Linie eine K & R-Klammer verwenden müssen, verschwenden Sie nicht den vertikalen Platz, der durch überflüssige Leerzeilen gespart wird.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Schreiben Sie das, was am besten lesbar und am wenigsten überraschend ist.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Diese Funktion benötigt keine 12 Zeilen Dokumentkommentare.

Tatsächlich braucht es keine Kommentare.

Oder leere Zeilen.

Sie würden von seinem Wesen ablenken.

Innerhalb der Funktion? Selten

Wenn ich einen anderen Block habe, wird auf eine neue Funktion umgestaltet. Wenn sich wenige Fälle nicht lohnen.

Für mich sind Leerzeilen innerhalb der Funktion eine der falschesten "Best Practices".

Häufig

Verwenden Sie es für logische Codeblöcke, die auf ähnliche Weise verarbeitet werden. Sobald Sie einen Kommentar hinzugefügt haben, um zu zeigen, dass Sie einen anderen Schritt ausführen, ist es Zeit, die Methode zu extrahieren.

Gutes Leerzeichen

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Schlechtes Leerzeichen

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

Ich benutze nicht nur Leerzeichen, sondern auch geschweifte Klammern.

Klammern, die ich benutze, um zu sagen, dass dies möglicherweise Funktionen sein können.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

Zu einer Zeit würde ich in meinem Code großzügig Leerzeilen streuen. Heutzutage bin ich eher sparsam. Ich glaube, das ist ein Teil dessen , was Steve Yegge wurde reden hier :

Hoffentlich hilft dir die Szene, die ich bisher gemalt habe, zu verstehen, warum du manchmal Code ansiehst und es einfach sofort hasst. Wenn Sie ein n00b sind, schauen Sie sich erfahrenen Code an und sagen, dass er undurchdringlicher, undisziplinierter Mist ist, der von jemandem geschrieben wurde, der nie die Grundlagen der modernen Softwareentwicklung erlernt hat. Wenn Sie ein Veteran sind, sehen Sie sich den Code n00b an und sagen, dass er überkommentiert ist und Zierflusen enthält, die ein Praktikant in einer einzigen Nacht mit starkem Alkoholkonsum hätte schreiben können.

Der Knackpunkt ist die Kompressionstoleranz. Wenn Sie im Laufe Ihrer Karriere Code schreiben, insbesondere wenn er sich über sehr unterschiedliche Sprachen und Problembereiche erstreckt, erhöht sich Ihre Toleranz für die Codekomprimierung. Es ist nicht anders als der Fortschritt vom Lesen von Kinderbüchern mit riesigen Texten zu immer komplexeren Romanen mit kleineren Texten und größeren Wörtern.

...

Ein Programmierer mit einer hohen Komprimierungstoleranz wird tatsächlich durch eine Reihe von Geschichten behindert. Warum? Denn um eine Codebasis zu verstehen, müssen Sie in der Lage sein, so viel wie möglich in Ihren Kopf zu packen. Wenn es sich um einen komplizierten Algorithmus handelt, möchte ein erfahrener Programmierer das Ganze auf dem Bildschirm sehen, was bedeutet, dass die Anzahl der Leerzeilen und Inline-Kommentare verringert wird - insbesondere Kommentare, die lediglich wiederholen, was der Code tut. Dies ist genau das Gegenteil von dem, was ein n00b-Programmierer möchte. n00bs möchten sich auf jeweils eine Anweisung oder einen Ausdruck konzentrieren und den gesamten Code aus dem Blickfeld rücken, damit sie sich konzentrieren und laut weinen können.

Ich stimme ihm grundsätzlich zu. Es ist viel besser, den Code zu komprimieren, damit Sie so viel wie möglich auf einem Bildschirm anzeigen können, als ihn zu sehr auszulagern. Das heißt nicht, dass Sie niemals Leerzeilen verwenden sollten. Es ist nur so, dass ich denke, wenn die Gruppierung, die Sie erstellen möchten, die Lesbarkeit nicht immens steigert, schadet sie mehr als sie nützt.

Ein emeritierter Professor gab zwei großartige Ratschläge

1. Whitespace ist kostenlos
2. Verwenden Sie nicht die Heftklammern, die sich auf der Vorderseite des Papiers befinden, sonst scheitere ich Sie.

Meine Faustregeln sind diese:

1. Wenn ich Probleme habe, den Code zu lesen, den ich gestern geschrieben habe, muss ich wahrscheinlich eine oder drei Methoden extrahieren.

2. Wenn meine Klassendefinition zu lang ist, um leicht gelesen zu werden, muss ich wahrscheinlich ein Modul / eine Schnittstelle / ein Objekt extrahieren.

3. Methodendefinitionen: Fügen Sie eine Zeile hinzu

4. Modul- / Klassendefinitionen: Fügen Sie zwei Zeilen hinzu

Ich stelle mir Leerzeichen gerne genauso vor wie Absätze. Sie gruppieren Linien, die zu einer Idee beitragen.

Wenn Sie eine neue Idee oder eine neue Facette derselben Idee beginnen, beginnen Sie einen neuen Absatz - so.

Im imperativen Code fasse ich Aufgaben zusammen, die eine zusammenhängende Aufgabe ausführen. Im deklarativen Code fasse ich Code zusammen, der eine zusammenhängende Aussage einer Idee beschreibt.

Sie haben eindeutig keine Probleme damit, dies auf Englisch zu tun (einige Leute haben schreckliche Probleme mit dem Paragraphen). Mit ein wenig Übung sollte es also kein Problem sein, dieselbe Fähigkeit auf Code anzuwenden.

Leerzeilen sind meiner Meinung nach ein Muss. Ich benutze sie, um verschiedene logische Codeblöcke zu trennen. Macht den Code lesbar. Lesbarer Code ist guter Code;)

Mein ideales Codestück wäre, dass jeder logische Block durch eine Leerzeile und einen Kommentar über jedem Block mit einer Hauptlogik getrennt wird.

Natürlich finde ich es sehr ärgerlich, wenn Leute es tun, indem sie überall mehrere Leerzeilen einfügen :(

Ich benutze nur Leerzeichen innerhalb einer Funktion / Methode, um Deklarationen und Code zu trennen.

Wenn Sie das Bedürfnis haben, einige Zeilen zum Trennen von Teilblöcken des Codes zu haben, die eine Logik implementieren, sollten sie sich nur in einer anderen Funktion / privaten Methode befinden. Es liegt an Ihrem Compiler, den Aufwand nicht zu groß zu machen.

In der Regel im Peusdo-Code:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Wenn ich unnütze Leerzeichen sehe, erschaudere ich normalerweise.

Leerraum ist extrem wertvoll.

Hier ist der Deal ... Nerds, die komplizierten Code wie E = MC ² schreiben, können ihre Programmierfähigkeiten hervorragend unter Beweis stellen.

Lassen Sie uns nun ein halbes Jahr weiterspringen, und es ist 2:00 Uhr morgens, und das System, das seit sechs Monaten nicht mehr untersucht wurde, ist genau in der Zeile E = MC ² defekt . Das ist fast unmöglich zu debuggen ... alle flippen aus.

Angenommen, der Code sieht ungefähr so ​​aus ...

See Dick
See Jane
See Dick and Jan

Wenn es 2:00 Uhr morgens ist und der Code fehlerhaft ist. Ein kurzer Blick zeigt Ihnen, dass Zeile drei hätte sein sollen

See Dick and Jane

Problem gelöst.

Fazit ... Leerzeichen verwenden.

Wie viele andere angegeben haben, erleichtern leere Zeilen das Lesen von Code. Es gibt jedoch einige Sprachen, die diesen Standard durchsetzen. Eines, an das ich auf Anhieb denken kann (nicht so sehr über Leerzeilen, sondern über die richtige Einrückung), ist Python.

Ich stimme zu, ich benutze Whitespace genauso. Wenn ich jedoch eine Methode mit Leerzeichen in zu viele Teile zerlege, muss ich den Code möglicherweise in mehrere Methoden umgestalten. Zu viele logische Abschnitte in einer Methode können darauf hinweisen, dass die Methode schwieriger zu testen ist.

Ich benutze sie, um Code in logische Einheiten zu trennen. Ich habe nur sehr wenige Codebeispiele gesehen, in denen keine Leerzeilen verwendet wurden. Eine Verschleierung ist natürlich ausgeschlossen.

Die Antwort des Psychopathen ist die beste, aber ich würde sie durch die Annahme ersetzen, dass die nächste Person ein Idiot ist und dass sie annehmen wird, dass Sie es sind, und dass Sie ihnen das Gegenteil beweisen wollen.

Ebenso wichtig für die Lesbarkeit ist die Verwendung von Kommentaren. Ich öffne jede Funktion oder Subroutine mit einem Kommentarblock und erkläre im Klartext, was es ist, was es tut, was die Argumente sind und was die erwarteten Ergebnisse sind (einschließlich einer Liste von Fehlerzuständen). Dann steht außer Frage, was beabsichtigt und / oder beabsichtigt ist. Was es erreicht, kann variieren, aber das ist weiter unten in der Spur.

Ich denke, viel zu viele Programmierer gehen entweder davon aus, dass sie selbst "Reparaturen" am Code vornehmen werden, oder es ist ihnen einfach egal.

Leerzeilen sind wichtig. Durch das Verschwenden einer ganzen Leerzeile in der öffnenden Klammer wird jedoch die Codemenge verringert, die auf einem Bildschirm angezeigt wird. Sollte sein:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Bring mich nicht dazu, die Klammer '{' in dieselbe Zeile wie das 'for' zu setzen ... das ist meshuggah).

Ja. Zur besseren Lesbarkeit. Manchmal füge ich sogar leere Zeilen in Code ein, die ich nicht geschrieben habe. Ich finde es einfacher, Code zu verstehen, wenn er über Leerzeilen logisch gruppiert ist - so wie man ihn "schnell lesen" kann.

Wir sollten Leerzeilen zwischen Codeblöcken verwenden, wie wir es tun, wenn wir einen Brief schreiben.

Zum Beispiel zwischen Funktionen oder innerhalb einer Funktion, wenn wir eine Schleife beenden ...

Die Leute werden sich bei Ihnen für einen sauberen Code bedanken, wenn sie ihn warten müssen;)

Wir verwenden die von Microsoft StyleCop empfohlenen Leerzeichen. Abgesehen von der Lesbarkeit und Konsistenz habe ich festgestellt, dass es (zusammen mit kleinen Klassengrößen) wesentlich einfacher ist, Zusammenführungen zu verwalten, wenn verschiedene Personen in einem Team zufällig in denselben Bereichen arbeiten.

Ich bin mir nicht sicher, ob es nur meine Vorstellungskraft ist, aber unterschiedliche Tools scheinen besser zu erkennen, wo gleichwertiger Code beim Zusammenführen beginnt und endet, wenn er ordentlich angeordnet ist. Schön gestalteter Code ist eine Freude zu verschmelzen. Ok, das war eine Lüge - aber der Schmerz ist immerhin auf einem überschaubaren Niveau.

Niemals eine leere Zeile, nicht in der gesamten Datei. Das heißt nicht, dass der Code keine Brüche enthält:

 code;
 //
 morecode;

Leerzeilen dienen zum Öffnen von Codeabschnitten. In Ihrem Editor befinden sich einige Tastenkombinationen, mit denen Sie zur vorherigen / nächsten Leerzeile gelangen.