Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

It seems to be fashionable recently to omit semicolons from Javascript. There was a blog post a few years ago emphasising that in Javascript, semicolons are optional and the gist of the post seemed to be that you shouldn't bother with them because they're unnecessary. The post, widely cited, doesn't give any compelling reasons not to use them, just that leaving them out has few side-effects.

Even GitHub has jumped on the no-semicolon bandwagon, requiring their omission in any internally-developed code, and a recent commit to the zepto.js project by its maintainer has removed all semicolons from the codebase. His chief justifications were:

  • it's a matter of preference for his team;
  • less typing

Are there other good reasons to leave them out?

Frankly I can see no reason to omit them, and certainly no reason to go back over code to erase them. It also goes against (years of) recommended practice, which I don't really buy the "cargo cult" argument for. So, why all the recent semicolon-hate? Is there a shortage looming? Or is this just the latest Javascript fad?

share|improve this question
2  
"years of recommended practice" refer a question of blacklisted SO polls tag which unlikely makes it authoritative to support any kind of opinion –  gnat Mar 29 '12 at 12:42
10  
@gnat just because people hate the question being on SO doesn't make it a less valid source of people's opinion. –  Ryathal Mar 29 '12 at 12:58
    
@Ryathal it's not about hate - eg, I wouldn't mind if OP referred to particular answer of that question that I could study - but this is not what I see. OP simply gives question link as if this automagically makes their statement authoritative - to which I object by pointing out that questions of that kind are officially considered inappropriate at SO. Fair enough? –  gnat Mar 29 '12 at 13:27
1  
@gnat Questions that are "officially considered inappopriate on StackOverflow" are sometimes considered very authoritative by the expert community. Sad but true. –  MarkJ Apr 4 '12 at 17:15
1  
@gnat The blacklisted question actually has some very interesting examples of why omitting the ; can break your code. So I'd say it's a useful reference for this question. –  Andres F. May 13 '13 at 12:22

6 Answers 6

up vote 13 down vote accepted

I suppose my reason is the lamest: I program in too many different languages at the same time (Java, Javascript, PHP) - that require ';' so rather than train my fingers and eyes that the ';' is not needed for javascript, I just always add the ';'

The other reason is documentation: by adding the ';' I am explicitly stating to myself where I expect the statement to end. Then again I use { } all the time too.

The whole byte count argument I find irritating and pointless:

1) for common libraries like jquery: use the google CDN and the library will probably be in the browser cache already

2) version your own libraries and set them to be cached forever.

3) gzip and minimize if really, really necessary.

But really how many sites have as their biggest speed bottleneck the download speed of their javascript? If you work for a top 100 site like twitter, google, yahoo, etc. maybe. The rest of us should just worry about the code quality not semicolon religious wars.

share|improve this answer
    
I guess the opposite could be true as well. As python becomes more popular for web it's easier to have your JS resemble python. –  Ben DeMott Mar 31 '12 at 8:37
    
Try but then the same byte warriors would be after me for unnecessary whitespace at the beginning of lines. ( I would also have Javascript bugs because I would rely on Python's indent rule rather than using { } –  Pat Apr 1 '12 at 11:21

I recently wrote a parser/analyzer for JavaScript, where I had to painstakingly implement ASI, and I also have my copy of Crockford's JavaScript: The Good Parts on my bookshelf, which advocates always using semicolons. The intention was good, but it doesn't always help in practice.

Obviously, the people writing frameworks like jQuery, zepto, etc. are JavaScript syntax masters and thus they know the difference between:

return
{
    status: true
};

and

return {
    status: true
};

JavaScript, while powerful, is also a beginner's language and good luck explaining this to someone who is just learning what a for loop is. Like introducing most people to a new skill, there are some more complex things you don't want to explain right away, so instead you choose to instill a "cargo cult" belief in certain things just to get them off the ground. So, you have two choices when teaching a beginner how to write JavaScript:

  1. Tell them "follow this one rule and don't ask why", telling them to put a always semicolon at the end of every line. Unfortunately, this doesn't help in the example in the above, or any other example where ASI gets in the way. And Mr. or Ms. beginner programmer gets befuddled when the code above fails.
  2. Tell them "follow these two rules and don't ask why", telling them not to bother with semicolons at the end of every line, and to instead always a) Follow return with a {, and b) When a line starts with a (, prepend it with a ;.

Choosing option 2 is a better set of "cargo cult" rules to follow (will result in very few ASI-related bugs), and even if you do get a deep understanding of the topic, you have fewer unneeded characters on the screen.

share|improve this answer
2  
All right, I'll bite. Help me understand the difference in syntax between the two examples above. My untrained eye only sees a difference in formatting. –  Jesse C. Slicer Mar 29 '12 at 20:27
3  
Or, on the other hand, I stumbled across the answer by sheer accident. In the first example, the return is considered a solitary statement and the line-end is the equivalent of a semicolon. The second example actually returns the object. Tricksy. –  Jesse C. Slicer Mar 29 '12 at 20:30
1  
I don't think I can agree with the idea that JavaScript is a beginners language, there are tons of inconsistencies and surprise effects in JavaScript that don't have simple explanations. IMO a beginners language wouldn't be like that, I would call JavaScript an intermediate language. –  Ryathal Mar 29 '12 at 20:32
    
@Ryathal I understand what you're getting at, but calling it an intermediate language makes me wonder what languages it inter-mediates. You make it sound as if it's a step on a journey to something else rather than a destination in it's own right. –  Racheet May 13 '13 at 16:43
    
Clarifying point: the return example is actually an exception to the normal JS behavior which is to attempt to pull lines together when a semi-colon is omitted. return, break, and continue all exhibit this exceptional behavior in which a trailing newline is always interpreted as an end of statement. (Source is Flanagan's "JavaScript: The Definitive Guide" pp25-26). Personally, I strive for the idea of "code of least surprise." Leaving semi-colons out tends to result in more surprises than anything (I generally also keep my curly braces even for simple statements). –  Kyle May 13 '13 at 16:58

semi colons in JavaScript are optional

My personal reason for not using semi colons is OCD.

When I use semi colons I forget 2% of them and have to constantly check / add them back in.

When I don't use semi colons I never accidentally put one in so I never have to check / remove them.

share|improve this answer
1  
Good one. I've been burned by a semicolon-less line or two in an otherwise properly semicoloned file. –  Jonathan Mar 29 '12 at 12:59
    
There are parsers (e.g. GeSHi) that will not parse your code correctly if semicolons are not present. You could say that humans will not make such mistakes... But seriously - event if all of your team will manage to remember where semicolons absolutely need to be put, do you really think they will remember it without morning coffee? And they will code in many states of minds. Be sure of it. –  Nux May 11 '13 at 17:08

It makes method chaining eaiser and commit diffs cleaner

So let's say I'm jQuerying about and I have

$('some fancy selector')
  .addClass()
  .attr();

If I want to add stuff and keep my line-based commit diff small, I have to add it above attr. So it's one thought longer than just "add at the end". And who wants to think? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

But, when I drop the semi-colons, I can just append and call it a day

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

Also, if I decide to pop off the last method, I don't have to reassign the semi-colon and pollute my commit again.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

Versus the uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();
share|improve this answer
4  
This is niche use case IMO. –  JBRWilkinson Mar 29 '12 at 22:30
2  
But interesting nevertheless. –  Jonathan Mar 30 '12 at 11:30
1  
You can have semicolon at the end on a new line indented as the starting line. Then you copy and reorder things as you wish. This also closes the chain nicely. –  Nux May 11 '13 at 17:38

I have two theories:

A)

The thing about this choice is that back in the day, when JSLint etc. were applicable, you were choosing to spend a large amount of time catching obscure syntax errors, or a reasonable amount of time enforcing a standards policy on code.

However, as we move more towards Unit Test-driven code and continuous integration the amount of time (and human interaction) required to catch a syntax error has decreased massively. Feedback from tests will quickly indicate if your code is working as expected, well before it gets near an end-user, so why waste time adding optional verbosity?

B)

Lazy programmers will do anything to make their own lives easier in the short term. Less typing -> less effort -> easier. (also, not having to semicolon will avoid straining your right-hand ring-finger, avoiding some RSIness).

(N.B. I disagree with the idea of omitting something that disambiguates a statement).

share|improve this answer
    
jshint is still an important tool. –  Raynos Mar 29 '12 at 16:40
    
As for disambiguating a statement, both \n and ;\n are the same –  Raynos Mar 29 '12 at 16:41
    
@Raynos Actually, I've found that JSLint tends to be a bit useless with the complexity of some of the framework-heavy code I often work with. Plus, ;\n and \n aren't the same in all circumstances, otherwise there'd never be a need for the ;. –  Ed Woodcock Mar 29 '12 at 16:48
4  
jslint is useless, jshint however is a different tool. –  Raynos Mar 29 '12 at 17:09

Choosing a programming convention is effectively the same as choosing subset of the target language. We all do this for the usual reasons: code readability, maintainability, stability, portability, etc. -- while potentially sacrificing flexibility. These reasons are real business reasons.

Reasons such as "saving keystrokes," and "programmers should learn the JavaScript rules" are marginal business reasons so they carry little practical weight.

In my case I needed to come up to speed in JavaScript very fast, so leveraging a limited subset of the language was to my advantage. So I chose the JSLint subset of JavaScript, turned on the Rockstar apps JSLinter in Eclipse to the most restrictive settings I could stand, and haven't looked back.

I'm grateful to be able to avoid the details of the difference between "==" and "===", or the details of semicolon insertion, because I've got a mile high task list already and those details won't help get those jobs done one second earlier.

Of course the most important thing about a convention is consistency, and thinking of it as a language subset helps to reinforce this imperative. And although this may not help answer the OP's question, I think it might help with the practical framing of it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.