• What are the dangers of breaking a line of long code up at a close parenthesis?

• When could a semicolon be automatically inserted by Javascript (presumably that is the danger, right?).

• Why is using a ) as a line breaker "frowned upon" by JSLint?

In Javascript I sometimes see one long line of code broken up at a ) like this (example):

function ()
{

or like this (example):

object.methodOne()
      .methodTwo();

But when reading the line break expectations for jsLint, it says:

As a further defense against the semicolon insertion mechanism, JSLint expects long statements to be broken only after one of these punctuation characters or operators:

, ; : { } ( [ = < > ? ! + - * / % ~ ^ | &
== != <= >= += -= *= /= %= ^= |= &= << >> || &&
=== !== <<= >>= >>> >>>=

JSLint does not expect to see a long statement broken after an identifier, a string, a number, closer, or a suffix operator:

. ) ] ++ --

So the close parenthesis is singled out as a line breaker that JSLint "doesn't expect to see."

I would prefer to use

function() 
{

since I find it more readable, and I already use it in other languages, but currently I use:

function () {

Could I safely use the ) to break up long lines?

• What are the dangers of breaking a line of long code up at a close parenthesis?

• When could a semicolon be automatically inserted by Javascript (presumably that is the danger, right?).

• Why is using a ) as a line breaker "frowned upon" by JSLint?

In Javascript I sometimes see one long line of code broken up at a ) like this (example):

function ()
{

or like this (example):

object.methodOne()
      .methodTwo();

But when reading the line break expectations for jsLint, it says:

As a further defense against the semicolon insertion mechanism, JSLint expects long statements to be broken only after one of these punctuation characters or operators:

, ; : { } ( [ = < > ? ! + - * / % ~ ^ | &
== != <= >= += -= *= /= %= ^= |= &= << >> || &&
=== !== <<= >>= >>> >>>=

JSLint does not expect to see a long statement broken after an identifier, a string, a number, closer, or a suffix operator:

. ) ] ++ --

So the close parenthesis is singled out as a line breaker that JSLint "doesn't expect to see."

I would prefer to use

function() 
{

since I find it more readable, and I already use it in other languages, but currently I use:

function () {

Could I safely use the ) to break up long lines?

• javascript
• line-breaks

• Note that jslint is purposely more defensive than the actual JS syntax, and it will plain about things that are valid Javascript (for instance, jslint considers ++ and -- to be bad). – Daniel Vandersluis Commented Sep 15, 2010 at 21:26
• @Daniel - I understand that, but I assume that there are still reasons for the rules... I'm just not sure what they could be in the case of the close paren. – Peter Ajtai Commented Sep 15, 2010 at 21:30
• 1 Although the function definition is 100% safe, there are other cases (see user166390's answer) where a ) at the end could cause problems. – casablanca Commented Sep 15, 2010 at 21:41
• 1 for clarity, I guess. Despite being valid, your second example could be misconstrued by a programmer who is reading it, or mistyped by a programmer who meant to specify a different object for the second method call. – Daniel Vandersluis Commented Sep 15, 2010 at 21:42
• You can use JsHint and chose which warnings you want. – Christophe Roussy Commented Oct 8, 2015 at 9:11

4 Answers 4

This link should explain it all:

JavaScript Semicolon Insertion

The "danger" is with (taken from the above link, emphasis added):

There are five restricted productions in the grammar, they are the postfix operators ++ and --, continue statements, break statements, return statements, and throw statements.

function() is not in that "danger" list. However, when writing semi-colon free-code (I'm not sure if this is your aim :-), one should guard against lines starting with characters -- such as ( or [ -- that may start or continue an expression. The following code shows an example of code which is likely wrong:

x()
(function (){...})()

As you can see, using ) as a line-breaker may make the expression able to continue on subtly without an explicit semi-colon iff the next line can continue the expression. I write the proceeding as (if the following is indeed the intent):

x()
;(function (){...})()

Personally, I dislike JSLint :-) Happy coding.

When you're trying to return an object,

return {
 'foo': 'bar'
}

will return the object, whereas

return
{
  'foo': 'bar'
}

will return undefined. Javascript will automatically insert a semicolon after return in the second example, and the object will never be reached.

For functions, because function() isn't valid on its own, it shouldn't make a difference if the brace is on the same line or the next.

See also section 7.9.1 Rules of Automatic Semicolon Insertion of the ECMAScript specification. Aside from return, there are four other situations where a semicolon will be inserted due to a newline: break, continue, throw and ++ or --.

When a continue, break, return, or throw token is encountered and a LineTerminator is encountered before the next token, a semicolon is automatically inserted after the continue, break, return, or throw token.

A semicolon will be inserted only if the following line is not a valid continuation of the previous line (see exceptions below). So function() { with { on the next line is always safe.

From the ECMAScript spec:

When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:

• The offending token is separated from the previous token by at least one LineTerminator.

• The offending token is }.

Exceptions to this rule are the increment/decrement operators, continue, break, return and throw, whose arguments must always be on the same line:

When a ++ or -- token is encountered where the parser would treat it as a postfix operator, and at least one LineTerminator occurred between the preceding token and the ++ or -- token, then a semicolon is automatically inserted before the ++ or -- token.

When a continue, break, return, or throw token is encountered and a LineTerminator is encountered before the next token, a semicolon is automatically inserted after the continue, break, return, or throw token.

It is safe.

I took a quick look at the semicolon insertion rules in the spec (3rd edition), and for function declarations it is OK.