Erläuterung des fehlerhaften Zeilenumbruchs von JSHint vor dem Fehler '+'


125

Kann mir jemand erklären, warum sich JSHint über Folgendes beschwert:

window.location.href = String1
    + '#'
    + Sting2
    + '='
    + String3;

Mit dem Fehler, Bad line breaking before '+' error

Ich verstehe, dass dieser Fehler mit der laxbreak Option konfiguriert werden kann , die als beschrieben wird

Diese Option unterdrückt die meisten Warnungen vor möglicherweise unsicheren Zeilenumbrüchen in Ihrem Code. Es werden keine Warnungen bezüglich des Komma-First-Codierungsstils unterdrückt. Um diese zu unterdrücken, müssen Sie laxcomma verwenden (siehe unten).

Diese Erklärung ist ziemlich knapp und ich bin gespannt, warum das Brechen von Linien auf diese Weise überhaupt als schlecht oder nachlässig angesehen wird.

Denken Sie daran, ich versuche hier nicht, einen heiligen Krieg zu beginnen, ich suche nur nach einer objektiven Antwort darauf, warum die JSHint-Leute dies für schlecht halten, ob es nur eine Stilpräferenz ist, die sie in ihren Linter injizieren (ich dachte, JSLint war es der meinungsgebundene Linter) oder wenn bei bestimmten Interpreten etwas schief gehen kann, wenn die Linie auf diese Weise unterbrochen wird.


6
Ich denke, es ist laut JSHint nur "schlechter Stil". Sie erhalten den gleichen Effekt, wenn Sie führende Kommas verwenden. Zur besseren Lesbarkeit würde ich es zumindest mit dem + am Ende der Zeile umschreiben.
Iwan

28
Schade. Ich denke, dieser Stil ist absolut der am besten lesbare Stil für mehrzeilige Zeichenfolgen, insbesondere wenn der Code in einem engen Fenster angezeigt wird.
Lambart

12
Das Führen mit Token, die die Anweisung fortsetzen, hilft dabei, die Dinge auszurichten und die Fortsetzung im linken Teil des Codeblocks visuell auszudrücken. Hier würde man erwarten, die Strukturelemente zu finden, insbesondere wenn schnell gescannt wird. Es ist definitiv tragfähig und vernünftig und objektiv gesehen kein schlechter Stil. Es gibt jedoch ein Problem mit der Codeintegrität bei der Durchsetzung dieser Regel, das bedauerlich ist.
Adam Tolley

1
@AdamTolley Ich stimme vollkommen zu, und als ich danach fragte, bekam ich eine Bestätigung, dass dies FUD war. Es wurde nach "Meta-Effekt" unter die Lupe genommen; und diese Prüfung schien zu bestätigen, dass dies machbar und vernünftig ist.
HostileFork sagt, vertraue SE

2
Heutzutage ( JSHint 2.9.4 ) lautet die Fehlermeldung Irreführender Zeilenumbruch vor '+'; Leser können dies als Ausdrucksgrenze interpretieren.
RhinoDevel

Antworten:


107

Es ist ein Styleguide, um Aussagen zu vermeiden, die Annahmen über das automatische Einfügen von Semikolons unterliegen könnten .

Die Idee ist, dass Sie am Ende einer Zeile klar machen, ob der Ausdruck dort endet oder in der nächsten Zeile fortgesetzt werden kann.


6
Vielen Dank für die Antwort. Wenn ich eine Begründung für den Fehler habe, kann ich die Änderungen zur Beruhigung von JSHint viel einfacher rechtfertigen.
James McMahon

36
Das automatische Einfügen von Semikolons ist eine vernünftige Begründung für die Durchsetzung dieses Stils. Wenn sich der Ausdruck jedoch in einer Klammer befindet, bleibt die Warnung bestehen. Und das macht mich traurig.
Ben Hyde

23
zweite @BenHyde, und im Allgemeinen ist es besser lesbar, wenn Sie den Code durchblättern, um die Zeile mit a zu führen +. Es ist für die Augen einfacher (und weniger fehleranfällig), einer einzelnen Spalte links zu folgen, als zum anderen Ende jeder Zeile zu springen, um zu sehen, ob sie an die nächste Zeile angehängt wird. Sogar die Grammatik ist weniger klobig: "Zeile 118 hängt 117 an" im Vergleich zu "Zeile 117 wird von Zeile 118 angehängt."
Worc

9
Persönlich hasse ich es, Operatoren (und Kommas) an das Zeilenende anzuhängen, weil ich daran vorbeigehe. Es ist für mich einfacher, die Logik in mehrzeiligen booleschen Anweisungen (&& oder || am Anfang einer Zeile statt am Ende) zu lesen, und ich kann durch Kommas getrennte Listen schnell von anderen mehrzeiligen Anweisungen unterscheiden, indem ich sie mit a beginne Komma. Gott sei Dank für laxbreak
aaaaaa

2
@Barney Wie vereinbaren Sie die Besorgnis über das automatische Einfügen von Semikolons mit den Antworten auf meine sehr ähnliche Frage ? Was ist das vertretbare Risiko dieses Formats? Für mich hat es den Vorteil der Scannbarkeit.
HostileFork sagt, vertraue SE

8

Jshint kennzeichnet dies nicht als fehlerhaften Zeilenumbruch, wenn Sie das + vor dem Zeilenumbruch verwenden, im Gegensatz zu in der neuen Zeile. Wie so:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;

10
Dies beantwortet die Frage nicht einmal ein Jota. Warum so viele Up-Votes?
Lambart

4
Vielleicht, aber dies ist eine Möglichkeit, dieses Problem zu umgehen, ohne Ihre jshint-Einstellungen ändern zu müssen.
Asulaiman

4
Dies sollte ein Kommentar sein, da er die Frage nicht wirklich beantwortet, aber wertvolle Informationen liefert.
Tomtomssi

3

Keine direkte Antwort auf die Frage, aber für alle, die von Googling (wie ich) darauf stoßen und die Regel beibehalten, aber die Warnungen korrigieren möchten, kann Folgendes nützlich sein ...

Bei Verwendung von Notepad ++ (z. B. mit dem JSLint-Plugin) kann dies mithilfe der folgenden Suche und Ersetzung behoben werden:

  • Finde was: (\r\n|\n|\r)( *)\+
  • Ersetzen durch: (einschließlich des ersten und letzten Leerzeichens) +$1$2 
  • Suchmodus: Regulärer Ausdruck

(Nur unter Windows getestet, aber der Regex sollte auch mit Unix- oder Mac OS-Zeilenenden funktionieren.)

Gehen Sie eine ähnliche Sache für ||, &&, ==, !=, <=oder >=statt +, verwenden Sie diese:

  • Finde was: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Ersetzen durch: (einschließlich des ersten und letzten Leerzeichens) $3$1 $2 

5
Nützlich vielleicht für Leute, die ihre Formatierung ändern möchten. Aber es beantwortet die (implizite) Frage überhaupt nicht: "Ich bin gespannt, warum das Brechen von Linien auf diese Weise überhaupt als schlecht oder lasch angesehen wird."
Lambart

Fairer Punkt, habe oben einen Hinweis hinzugefügt, der erklärt, warum ich dies gepostet habe.
Steve Chambers
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.