131

Can someone explain to me why JSHint complains about the following,

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

With the error, Bad line breaking before '+' error

I understand that this error can be configured with the laxbreak option, which is described as

This option suppresses most of the warnings about possibly unsafe line breakings in your code. It doesn't suppress warnings about comma-first coding style. To suppress those you have to use laxcomma (see below).

This explanation is pretty terse and I am curious about why breaking lines this way is considered bad or lax in the first place.

Keep in mind I am not trying to start a holy war here, I am just looking for an objective answer about why the JSHint folks think this is bad, whether it is just a style preference they are injecting into their linter (I thought JSLint was the opinionated linter), or if there is something that can go wrong on certain interpreters when line breaking this way.

James McMahon
  • 48,506
  • 64
  • 207
  • 283
  • 6
    I think it's just "bad style" according to JSHint. You'd get the same effect if you use leading commas. For readability I'd at least rewrite it with the + at the end of the line. – Iwan Feb 28 '13 at 16:36
  • @Iwan, you should make your comment into an answer. – James McMahon Feb 28 '13 at 16:47
  • 30
    Bummer. I think this style is absolutely the most readable style to use with multi-line strings, especially when viewing the code in a narrow window. – Lambart Jul 28 '14 at 19:15
  • 12
    leading with tokens that continue the statement help align things and visually express continuation in the left portion of the code block, which is where one would expect to find the structural elements, especially if scanning quickly. It's definitely viable and reasonable and not, objectively, bad style. There is, however, a code integrity issue for enforcing this rule, which is unfortunate. – Adam Tolley Oct 07 '14 at 21:21
  • 1
    @AdamTolley I completely agree, and [when I asked about this](http://stackoverflow.com/questions/24858171/) got what seemed to be confirmation that this was FUD. It was brought under scrutiny after "meta effect"; and that scrutiny seemed to confirm this is viable and reasonable. – HostileFork says dont trust SE Mar 20 '15 at 01:45
  • 1
    @JamesMcMahon > wither it is just a style preference Maybe you mean "whether"? – sigod Apr 29 '15 at 07:39
  • 2
    Nowadays ([JSHint 2.9.4](http://jshint.com)) the error message is _Misleading line break before '+'; readers may interpret this as an expression boundary._ – RhinoDevel May 17 '17 at 07:21

3 Answers3

112

It's a style guide to avoid statements that could be liable to assumptions about automatic semicolon insertion.

The idea is that you make it clear by the end of a line whether the expression ends there or could be continued on the next line.

Community
  • 1
  • 1
Barney
  • 16,181
  • 5
  • 62
  • 76
  • 6
    Thanks for the answer, having a rationale behind the error makes it a lot easier for me to justify making the changes to appease JSHint. – James McMahon Feb 28 '13 at 18:35
  • 1
    "if you replaced window.location.href = with return, only String1 would be processed" - this isn't the case – thorn0 Jul 19 '13 at 09:03
  • 1
    @thorn you're absolutely right — I don't know where I got that notion but under examination it's flat out wrong. Thanks for the heads up! – Barney Jul 22 '13 at 11:05
  • 38
    Automatic semicolon insertion is a reasonable rational for this style being enforced. But when the expression is within some parenthesis the warning persists. And, that makes me sad. – Ben Hyde Mar 25 '14 at 15:35
  • 25
    second @BenHyde, and in general it's more human-readable when skimming through code to lead the line with a `+`. it's easier on the eyes (and less prone to error) to follow a single column on the left than jumping to the far end of each line to see if it's going to be appended by the next line. even the grammar is less clunky: "Line 118 appends 117" versus "Line 117 is going to be appended by Line 118." – worc Aug 21 '14 at 20:51
  • It's funny — parentheses are incredibly important in Javascript but even tools built exist let for Javascript (like JSHint) don't seem to cater for them. Highly function-oriented code will involve lot's of nested code in parens and yet I can't find a code editor that folds parens either. – Barney Aug 24 '14 at 17:51
  • 10
    Personally, I hate appending operators (and commas) to the end of lines because I skim past it. It's easier for me to read the logic in multi-line boolean statements (&& or || at beginning of a line instead of at the end), and I can quickly tell comma delimited lists apart from other multi line statements by beginning them with a comma. Thank god for laxbreak – aaaaaa Jan 13 '15 at 05:57
  • 2
    @Barney How do you reconcile the concern about automatic semicolon insertion with the answers [given to my very similar question](http://stackoverflow.com/questions/24858171/)? What is the justifiable risk of this format? To me it has the edge in scannability. – HostileFork says dont trust SE Mar 20 '15 at 01:47
  • @HostileFork it's a really contentious thing. Scannability isn't unanimously qualified nor scientifically well documented (different people just read differently). Personally I believe the above (operator first) is great — and actually the risk of unexpected ASI is tiny — but conversely I hate comma-first arrays. The jsHint setup for that is `/* jshint laxbreak : true, laxcomma : false */`. – Barney Mar 20 '15 at 08:34
  • @Barney Your comment looks like great content to integrate into the answer! *(The contention, your agreement in preference, and the settings necessary to overcome it!)* Although I still am looking to understand this "risk"...as I never understood what the risk scenario actually is. – HostileFork says dont trust SE Mar 20 '15 at 08:36
  • 1
    AFAICT the risk is that someone looks at one of the lines in absence of the others and moves it or deletes it, believing it to be self-contained, without realising that it's part of a multi-line expression. So the automatic semicolon insertion is in the user's mind rather than in the Javascript parser. – Barney Mar 20 '15 at 09:05
13

Jshint wont flag this as a bad line break if you use the + before the line break as opposed to in the new line. Like so:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;
asulaiman
  • 1,221
  • 12
  • 18
3

Not a direct answer to the question but for anyone coming across this from Googling (as I did) who wish to keep the rule but fix the warnings, the following may be useful...

When using Notepad++ (e.g. with JSLint plugin), this can be fixed using the following search & replace:

  • Find what: (\r\n|\n|\r)( *)\+
  • Replace with:  +$1$2  (including the first and last space)
  • Search Mode: Regular expression

(Only tested on Windows but the regex should also work with Unix or Mac OS line endings.)

To do a similar thing for ||, &&, ==, !=, <= or >= instead of +, use this:

  • Find what: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Replace with:  $3$1 $2  (including the first and last space)
Steve Chambers
  • 37,270
  • 24
  • 156
  • 208
  • 5
    Useful, perhaps, for folks who want to change their formatting. But it completely fails to answer the (implied) question: "I am curious about why breaking lines this way is considered bad or lax in the first place." – Lambart Aug 12 '15 at 00:34
  • Fair point, have added a note at the top explaining why I posted this. – Steve Chambers Aug 25 '15 at 14:25