I've got this error message, that I'm not a fan of.

Bad line breaking before '?'.

I feel like

var s = (a === b)
        ? 'one'
        : 'two';

looks better. Crockford says:

Semicolon insertion can mask copy/paste errors. If you always break lines after operators, then JSLint can do a better job of finding those errors.

Can someone give me an example or two, of the kind of copy/paste errors he's referring to?

Update:

var s = (a === b)
        ? 'one'
        : 'two';

looks better than

var s;
if(a === b) {
    s = 'one';
} else {
    s = 'two';
}

I've got this error message, that I'm not a fan of.

Bad line breaking before '?'.

I feel like

var s = (a === b)
        ? 'one'
        : 'two';

looks better. Crockford says:

Semicolon insertion can mask copy/paste errors. If you always break lines after operators, then JSLint can do a better job of finding those errors.

Can someone give me an example or two, of the kind of copy/paste errors he's referring to?

Update:

var s = (a === b)
        ? 'one'
        : 'two';

looks better than

var s;
if(a === b) {
    s = 'one';
} else {
    s = 'two';
}

• javascript
• jslint

• 1 If you're going to use a multi-line ternary if, why don't you just use a normal if statement? – Blender Commented Nov 14, 2012 at 22:28
• One line expression looks better a === b ? 'one' : 'two';, and without extra parentheses – zerkms Commented Nov 14, 2012 at 22:28
• 1 @Blender: ternary operator isn't ternary if – zerkms Commented Nov 14, 2012 at 22:28
• @zerkms: What's the proper name for it? – Blender Commented Nov 14, 2012 at 22:30
• 2 The "obvious" copy/paste error in the example you show would be to copy the first line var s = (a === b), which of course is valid code on its own but clearly doesn't do the same thing as the three lines together. One would hope that people would look at surrounding code before copying one line, but you never know. Having said that, I don't stress about that operator in my own code. I put a short ternary expression on one line, a longer one over two lines with the line break after the middle operand and the : lined up under the ?, or a really long one on three lines like yours. – nnnnnn Commented Nov 14, 2012 at 22:47

4 Answers 4

(As requested, my comments re-posted as an answer:)

The "obvious" copy/paste error in the example you show would be to copy the first line:

var s = (a === b)

...which of course is valid code on its own but clearly doesn't do the same thing as the three lines together. One would hope that people would look at surrounding code before copying one line, but you never know.

The point that I think Mr Crockford is trying to make is that if you deliberately split a multi-line expression up in a way that the individual lines are not valid code on their own, then if you accidentally copy just one line of the expression it will likely cause a syntax error when you paste it somewhere else. Which is good because syntax errors are reported by the browser and/or JSLint/JSHint, and so easier to find than the more subtle bugs created if you copy/paste a line that is valid on its own. So if you "always break lines after operators" as Crockford suggest:

var s = (a === b) ? 
        'one' : 
        'two';​

...then the only line of the ternary that is valid code on its own (the third) doesn't really look complete, and so would be easier to spot as a mistake if pasted on its own because it so obviously doesn't do anything on its own - and it's less likely to be copied by itself in the first place for the same reason.

(Having said that, I don't stress about the ternary operator in my own code, and I think the above looks ugly. I put a short ternary expression on one line, a longer one over two lines with the line break after the middle operand and the : lined up under the ?, or a really long one on three lines like yours.)

The most (in)famous example is as follows:

function one() {
  return
  {
    val: 1
  };
}

alert(one()); // undefined

vs

function one() {
  return {
    val: 1
  };
}

alert(one()); // [objet Object]

The type of copy-paste errors he's referring to are the ones where you hand your code off to someone else, or yourself in 6 months, and that other person haphazardly copies your code, ending on the closing paren of the condition, assuming that the assignment is meant to be the value of the evaluated right-hand side.

This seems implausible, and in a sense, you would hope that it is...
But I know that auto-insertion has borked code for my company multiple times, now, and they still haven't forced adoption of explicit semicolons, still treat JS as if new lines were significant and still make cut/paste errors, through neglect plus lack of tools/version-management/build-systems.

Say you paste a function expression in immediately before,

var a = 1, b = 1; // a === b, expect 'one'
(function(){
    console.log('called');
})
(a === b)
? 'one'
: 'two'
// called
// "two"