The indentation debate has spawned a couple of long threads here in the past (as has the allied question, spaces vs. tabs).
In JavaScript, K&R style has the distinct advantage of avoiding a bug in that language. Once you're in the habit of writing the opening brace on the same line as the statement that introduces it, you would have to go out of your way to write the incorrect
return
{
key: value
};
Three design decisions collude here to cause the bug: (1) statement blocks and object literals have the same delimiters; (2) expressions ⊆ statements; and (3) automatic semicolon insertion.
(1) means you either want to indent object literals the way you indent statement blocks and vice versa, or you want different rules for braces depending on what they're delimiting.
(2) says that any expression is a statement - it doesn't have to be an assignment or a function call or something else with obvious side effects to stand on its own as a statement. In particular, object literals can stand on their own as statements. But if
(3) complete statements are on distinct lines, the semicolon between them is optional - the line break is presumably enough separation. During parsing a semicolon is automatically inserted between them if there isn't one already there.
So the JavaScript parser sees [font=monospace]return[/font] on one line, and an object literal (which is an expression, which is a statement) on the following lines. They're on different lines so they look like two complete statements. So the semicolon between them was optional. And since there isn't one there, it is inserted.
return;
{
key: value
};
Interpreted as "return undefined" and execution never reaches the literal.
