36

The following code illustrates an object literal being assigned, but with no semicolon afterwards:

var literal = {
    say: function(msg) { alert(msg); }
}
literal.say("hello world!");

This appears to be legal, and doesn't issue a warning (at least in Firefox 3). Is this completely legal, or is there a strict version of JavaScript where this is not allowed?

I'm wondering in particular for future compatibility issues... I would like to be writing "correct" JavaScript, so if technically I need to use the semicolon, I would like to be using it.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mike Stone
  • 44,224
  • 30
  • 113
  • 140
  • I'm pretty sure that will break on IE. While it may be valid javascript, you probably have to add the semicolon because of that anyway – Orion Edwards Sep 03 '08 at 20:36
  • 1
    Semi-colons are optional, but your code will become invalid if you run it through a JavaScript minimizer such as the YUI Compressor. Therefore, its a good practice to always include semi-colons. – Ricky Sep 03 '08 at 18:26

7 Answers7

40

Not technically, JavaScript has semicolons as optional in many situations.

But, as a general rule, use them at the end of any statement. Why? Because if you ever want to compress the script, it will save you from countless hours of frustration.

Automatic semicolon insertion is performed by the interpreter, so you can leave them out if you so choose. In the comments, someone claimed that

Semicolons are not optional with statements like break/continue/throw

but this is incorrect. They are optional; what is really happening is that line terminators affect the automatic semicolon insertion; it is a subtle difference.

Here is the rest of the standard on semicolon insertion:

For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

Patrick Roberts
  • 49,224
  • 10
  • 102
  • 153
Jason Bunting
  • 58,249
  • 14
  • 102
  • 93
16

The YUI Compressor and dojo shrinksafe should work perfectly fine without semicolons since they're based on a full JavaScript parser. But Packer and JSMin won't.

The other reason to always use semi-colons at the end of statements is that occasionally you can accidentally combine two statements to create something very different. For example, if you follow the statement with the common technique to create a scope using a closure:

var literal = {
    say: function(msg) { alert(msg); }
}
(function() {
    // ....
})();

The parser might interpret the brackets as a function call, here causing a type error, but in other circumstances it could cause a subtle bug that's tricky to trace. Another interesting mishap is if the next statement starts with a regular expression, the parser might think the first forward slash is a division symbol.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Daniel James
  • 3,899
  • 22
  • 30
  • 1
    I recently ran into a similar issue (again due to a closure following an assignment). This is a very likely scenario and is a good argument for consistent usage of semicolons. +1 – Ates Goral Jul 23 '09 at 04:13
8

JavaScript interpreters do something called "semicolon insertion", so if a line without a semicolon is valid, a semicolon will quietly be added to the end of the statement and no error will occur.

var foo = 'bar'
// Valid, foo now contains 'bar'
var bas =
    { prop: 'yay!' }
// Valid, bas now contains object with property 'prop' containing 'yay!'
var zeb =
switch (zeb) {
  ...
// Invalid, because the lines following 'var zeb =' aren't an assignable value

Not too complicated and at least an error gets thrown when something is clearly not right. But there are cases where an error is not thrown, but the statements are not executed as intended due to semicolon insertion. Consider a function that is supposed to return an object:

return {
    prop: 'yay!'
}
// The object literal gets returned as expected and all is well
return
{
    prop: 'nay!'
}
// Oops! return by itself is a perfectly valid statement, so a semicolon
// is inserted and undefined is unexpectedly returned, rather than the object
// literal. Note that no error occurred.

Bugs like this can be maddeningly difficult to hunt down and while you can't ensure this never happens (since there's no way I know of to turn off semicolon insertion), these sorts of bugs are easier to identify when you make your intentions clear by consistently using semicolons. That and explicitly adding semicolons is generally considered good style.

I was first made aware of this insidious little possibility when reading Douglas Crockford's superb and succinct book "JavaScript: The Good Parts". I highly recommend it.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
JesDaw
  • 151
  • 5
3

In this case there is no need for a semicolon at the end of the statement. The conclusion is the same but the reasoning is way off.

JavaScript does not have semicolons as "optional". Rather, it has strict rules around automatic semicolon insertion. Semicolons are not optional with statements like break, continue, or throw. Refer to the ECMA Language Specification for more details; specifically 11.9.1, rules of automatic semicolon insertion.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
TonyLa
  • 746
  • 4
  • 6
0

Use JSLint to keep your JavaScript clean and tidy

JSLint says:

Error:

Implied global: alert 2

Problem at line 3 character 2: Missing semicolon.

}

nhahtdh
  • 55,989
  • 15
  • 126
  • 162
Geoff
  • 9,340
  • 7
  • 38
  • 48
  • 1
    The problem with JSLint is that it was written by Douglas Crockford who believes that semi-colons should be mandatory. Thus the alert. – staticsan Jul 09 '09 at 05:36
  • 5
    @staticsan - It's not just a personal belief. Requiring semi-colons at the end of every line means that the js file can be minified into a single line file. – Geoff Jul 09 '09 at 11:04
  • I am unclear about the virtue of a "single line file" when the semicolon character takes as many bytes as the newline character. What is the point of that sort of "minification"? – EFC May 11 '18 at 04:32
  • @EFC, you're right for lines that end with semicolons, but there are a lot of other newlines that get removed at the end of many other lines. Empty lines, lines that end with a brace or parentheses, etc. – Geoff May 14 '18 at 16:32
  • Sure, @Geoff, I get that. Some newlines can be removed. But it seems minification must always be sensitive to syntax so as not to break things, and in terms of shrinking code size using a newline is no more "expensive" than using a semicolon. A "single line file" is not the point, a "small file" is the point. If one insists on a "single line file" then replace the (appropriate) new lines with semicolons. In fact, the minifiers I use do this all the time with no trouble, so I'm puzzled about why this is an issue. Are extra semicolons a crutch for poor minifiers and linters? – EFC May 14 '18 at 16:59
  • 1
    @EFC, again yes you're correct, and in the almost 10 years since I wrote this answer minifiers are A LOT smarter than they used to be. And if, like me, you are stuck in Windows where we have CRLF line endings, then a carriage return is in fact one byte larger than a semicolon in UTF-8. 0a0d vs 3b hex – Geoff May 14 '18 at 18:13
0

The semi-colon is not necessary. Some people choose to follow the convention of always terminating with a semi-colon instead of allowing JavaScript to do so automatically at linebreaks, but I'm sure you'll find groups advocating either direction.

If you are looking at writing "correct" JavaScript, I would suggest testing things in Firefox with javascript.options.strict (accessed via about:config) set to true. It might not catch everything, but it should help you ensure your JavaScript code is more compliant.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Travis
  • 576
  • 5
  • 13
-1

This is not valid (see clarification below) JavaScript code, since the assignment is just a regular statement, no different from

var foo = "bar";

The semicolon can be left out since JavaScript interpreters attempt to add a semicolon to fix syntax errors, but this is an extra and unnecessary step. I don't know of any strict mode, but I do know that automated parsers or compressors / obfuscators need that semicolon.

If you want to be writing correct JavaScript code, write the semicolon :-)

According to the ECMAscript spec, http://www.ecma-international.org/publications/standards/Ecma-262.htm, the semicolons are automatically inserted if missing. This makes them not required for the script author, but it implies they are required for the interpreter. This means the answer to the original question is 'No', they are not required when writing a script, but, as is pointed out by others, it is recommended for various reasons.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Kamiel Wanrooij
  • 12,164
  • 6
  • 37
  • 43