it-swarm.dev

Zeilenumbruch vor / nach dem Bediener

Während Suns Java Code-Konvention vorschlägt, Zeilenumbrüche vor den Operator zu stellen, stimmen viele andere Richtlinien nicht damit überein. Ich sehe keine offensichtlichen Vor- und Nachteile, daher gibt es Vorteile bei der Verwendung eines dieser Stile gegenüber Ein weiterer?

String longVarName = a + b + c + d +
          e + f;

vs.

String longVarName = a + b + c + d
          + e + f;
31
Nutel

Ich würde es in einer Zeile belassen und lieber über die Lesbarkeit in Bezug auf absichtsstarke Variablennamen (und Funktionen) nachdenken.

Sobald es chaotisch wird, ist es Zeit für Refactor:

  • variablen umbenennen
  • neue Variablen/Funktionen einführen

Beispiel

subtotal = price * (100 + tax_ratio) / 100

vs.

tax = price * tax_ratio / 100
subtotal = price + tax
16
Kamil Tomšík

Normalerweise befolge ich die am häufigsten verwendeten Stilrichtlinien oder bestimmte Codierungsstandardwerkzeuge. Der Vorteil der Verwendung eines häufig verwendeten Stils bringt Vorteile, wenn Sie den Code anderer Personen lesen oder an einem Open Source-Projekt beteiligt sind, in dem Stilrichtlinien festgelegt sind.

Der häufigste Stil, den ich gesehen habe, ist der zweite Stil in der Frage. Die Liste finden Sie unten:

Google Style Guide :

Wenn bei einem Nichtzuweisungsoperator eine Zeile unterbrochen wird, steht die Unterbrechung vor dem Symbol.

Sun Coding Convention :

Pause vor einem Bediener

Checkstyle Operator Wrap Check 's Standardwert ist nl:

Der Bediener muss sich in einer neuen Leitung befinden

37
ceilfors

Ich kann mir Lesbarkeit als Argument vorstellen

result = longidentifier +
   short -
   alittlelonger -
   c;

versus

result = longidentifier
   + short
   - alittlelonger
   - c;

Im zweiten Beispiel sind die Operatoren gut ausgerichtet und Sie können leicht erkennen, mit welchem ​​Vorzeichen die Variable in die Gleichung eingeht. Ich denke, dass dies auch für binäre Operatoren sinnvoll ist, aber mit Klammern usw. sollten Sie einfach das tun, was klarer ist.

37

Im Code neige ich dazu, die Pause nach dem Operator zu setzen:

foo = some_long_expression() +
      some_other_long_expression();

Hier ist dieser baumelnde Operator am Ende einer Zeile ein großer Hinweis für den Leser, dass der Code fortgesetzt wird. In Sprachen ohne Anweisungsabschlusszeichen kann dieser baumelnde Operator als ausreichender Hinweis für den Compiler/Interpreter dienen, dass der Code fortgesetzt wird (andernfalls müsste ich ein hässliches Fortsetzungszeilenkonstrukt verwenden).

Wenn ich diesen Ausdruck dokumentiere (wenn er dokumentiert werden muss), neige ich dazu, die Pause vor den Operator zu stellen.

10
David Hammen

Ich glaube, die Zeile sollte mit dem höchsten Symbol im Analysebaum der Anweisung beginnen, die Sie unterbrechen möchten. Es hebt den Operator hervor, der im Ausdruck am wichtigsten ist. Es ist der gleiche Grund, warum Sie ein else am Anfang einer Zeile und nicht am Ende der vorherigen Zeile einfügen.

Im folgenden Beispiel sehen Sie beim Scannen des linken Randes die Struktur der Anweisung als OR von 3 Ausdrücken.

if (ch>='A' && ch<='Z'
    || ch>='a' && ch<='z'
    || ch>='0' && ch<='9')
{...}

Unten das || Operatoren sind weniger hervorgehoben. Es ist weniger offensichtlich, dass es sich um ein || handelt von Ausdrücken. Besonders wenn die Linien unterschiedlich lang waren.

if (ch>='A' && ch<='Z' ||
    ch>='a' && ch<='z' ||
    ch>='0' && ch<='9')
{...}

Und nur als Referenz, das ist sehr falsch. Die || Operatoren werden überhaupt nicht hervorgehoben.

if ( ch>='A' && ch<='Z' || ch>='a'
     && ch<='z' || ch>='0' && ch<='9')
{...}

Ich setze sogar gerne Kommas an den Anfang der Zeile, obwohl ich das selten sehe. Ich verzichte darauf, dies mit gemeinsam genutztem Code zu tun.

var note:Object =
    { key: key
    , type: 'P'
    , text: someLongProcedureCallGettingTheUserInitials()
       + ": " + getTheTextThatWasTyped()
    };
3
Florian F

Solange Sie konsequent bleiben, wissen Sie, dass es keinen wirklichen Vorteil gibt. Dies ist besonders wichtig, wenn Code-Zusammenführungen und Leerzeichen berücksichtigt werden.

3
Martijn Verburg

Für lange arithmetische Gleichungen mache ich normalerweise eines von zwei Dingen.

lass alles in einer einzigen Zeile:

foo = bar + baz - fizz + buzz + alpha - beta;

Ich mache dies normalerweise für Gleichungen, die nur Addition und Subtraktion enthalten. Ich finde es sehr einfach, einen Tippfehler mit Multiplikation und Division zu machen, der den Umfang des Operators ernsthaft durcheinander bringen kann.

das zweite Format, das ich verwende, sind progressive Operatoren:

foo = bar;
foo += baz;
foo -= fizz;
foo += buzz;
foo /= alpha - beta;
foo *= spiff;

Ich sehe keinen Grund, es auf eine einzelne Zeile zu verkürzen, es sei denn, es kann nachgewiesen werden, dass es die Leistung spürbar verbessert. Darüber hinaus gibt es keine Unklarheit darüber, was wo vor sich geht, und es besteht weniger die Möglichkeit, eine Klammer für das / und * Operatoren.

2
zzzzBov

Durch Platzieren des Verkettungszeichens (oder eines beliebigen Operators) am Zeilenanfang wird die Lesbarkeit verbessert. Wir scannen Code, indem wir uns auf den Anfang jeder Zeile konzentrieren. Wenn eine Zeile mit einem Operator beginnt, kann der Leser erkennen, dass die Zeile eine Fortsetzung der vorherigen Anweisung ist, indem er dieses eine Zeichen scannt.

Lange mathematische Ausdrücke werden immer so gesetzt, dass jede neue Zeile mit einem Operator beginnt. Es gibt keinen Grund, warum Code dieser Konvention nicht folgen sollte.

2
kevin cline

Lassen Sie den Ausdruck in einer Zeile, und wenn er zu lang wird, teilen Sie ihn in kleinere Ausdrücke auf:

days = ((year * months_per_year) + month) * days_per_month + day

wird:

months = year * months_per_year + month
days = months * days_per_month + day

Wenn dies nicht möglich ist, finde ich es besser lesbar, vor dem Operator zu brechen und den Operator direkt unter der vorherigen Zuweisung beginnen zu lassen (wenn ich ihn unter die Variable setze, muss ich nachdenken und neu zentrieren, was angesichts des Ziels ärgerlich ist ist es, die Dinge leichter lesbar zu machen):

random = years * months_per_year 
         + month * days_per_month 
         + day * hours_per_day 
         + hour * minutes_per_hour 
         + minute * seconds_per_minute 
         + second
0
Joel