7 ms·

Poll: Semicolons in JavaScript

24 points by felixge 16y ago

Question: Should people always use semicolons in Javascript? For those unfamiliar with the matter, Javascript allows semicolons to be omitted sometimes, see: http://inimino.org/~inimino/blog/javascript_semicolons Update: This poll was started as a result of a discussion on the node.js mailing list: http://groups.google.com/group/nodejs/browse_thread/thread/35810f231cb289aa

felixge 16y ago
Personally I think the Google Javascript Style Guide has it right: > Relying on implicit insertion can cause subtle, hard to debug problems. Don't do it. You're better than that. http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Semicolons#Semicolons http://google-styleguide.googlecode.com/svn/trunk/javascript...
- uptown 16y ago
  Interesting that you use Google as the example for always using semi-colons with JavaScript. When writing a code-example on a white-board during my Google interview, I was using semi-colons throughout my code. One of the things the interviewer asked was why I was using semi-colons ... implying that my code wasn't as clean as it could be. We talked about whether they were needed or not, but his preference seemed to be that they weren't really necessary, and that I shouldn't have been including them in my code. I continue to use them in my code.
  - yock 16y ago
    Perhaps your interviewer asked the question to see if you could justify them, thus gauging your understanding of how the language is parsed at runtime. The fact that the conversation continued may indicate that he or she wasn't convinced by your answer?
    - dazzawazza 16y ago
      I think this is more likely. When interviewing the point is to find out how someone is thinking not if they agree with a coding standard.
    - uptown 16y ago
      Quite possible. It wasn't a turning-point in the interview or anything ... but a discussion that lasted longer than I would have expected given the topic.
      - mrfish 16y ago
        Did you get the job?
- felixge 16y ago
  FWIW: I would like to not use semicolons in JS. But the current "push" for that is IMHO a mix of ruby/python home sickness and "Let's do this because we are smart enough to do it right.". Both are terrible influences on style in any language.
- mathgladiator 16y ago
  I once wrote a tool to beautify javascript from a mangled/compress form and in doing so learn that implicit insertion is absolute evil. return { a : true } and return { a : true } are different and can cause many problems.
jacquesm 16y ago
For me it's a 'yes' based on the simple rule that explicit is always better than implicit. That sort of 'optimisation' seems to be really cool when you're just starting out in a language but in the long run it isn't worth it. The first time you're bitten in the behind by a subtle bug after a couple of hours searching you've given up a hundredfold the time you have saved up to that point by not having to type those ;s. At that point people usually 'get it'.
- KlausTrainer 16y ago
  > For me it's a 'yes' based on the simple rule that explicit is always better than implicit. That sort of 'optimisation' seems to be really cool when you're just starting out in a language but in the long run it isn't worth it. I don't really get what you call implicit when you terminate statements with semicolons instead of linebreaks... ... Ok, I get what you're hinting it: there are some (very) few exceptions. However, I cannot see where there is any 'optimisation' in using linebreaks instead of semicolons. You better need to explain why someone should use both linebreaks _and_ semicolons, when only using linebreaks is actually as good as well. Basically, it's just a matter of style. Aside from a few exceptions (e.g. described in http://inimino.org/~inimino/blog/javascript_semicolons http://inimino.org/~inimino/blog/javascript_semicolons), linebreaks terminate a statement. If you stick with writing only one statement per line, I don't see what's so implicit with it. Rather terminating a statement both with a line break and a semicolon is a tautology, and hence introduces unnecessary redundancy. The actual question is, whether one can require that developers know the (maybe a handful) exceptions where a line break doesn't terminate a statement. I have decided (for myself) that I can require that knowledge, as it really comes down to only a few exceptions (that I believe are easy to remember). But, of course, I'm aware that one can also come do another reasonable conclusion. The only important thing is that people make a concious decision about the issue at all. The importance of this increases with the number of people that are working together on a particular project. Here a link to another article discussing that issue: http://mislav.uniqpath.com/2010/05/semicolons/ http://mislav.uniqpath.com/2010/05/semicolons/
  - jasonkester 16y ago
    But linebreaks don't terminate statements in javascript. x = y /* TODO: clean this up to make it more readable * and maybe add some semicolons */ + 4 ... is a single statement.
deleted 16y ago
[deleted]
troels 16y ago
When the curly-braces-syntax is replaced with proper sexp, I'm all for it. Until then, I prefer to keep the semicolons.
- mahmud 16y ago
  Parenscript; the happy amalgamation of Common Lisp and JavaScript, in your server or your browser. http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/ People are writing Node.js code in it :-) http://tryparenscript.com/ http://tryparenscript.com/ It reminds me of an old Scheme dialect, implemented in Common Lisp, and was used to implement the Yale Haskell compiler (by Sandra Loosemore[1], et al.); it's just one of those baroque language towers that you're not sure how it works, but somehow works perfectly. Combine parenscript with CSS-Lite[2] and you enter a weird world of web development in 100% Lisp (not entirely good though; you wont be able to cut-and-paste stuff from SO, but then, thinking for yourself might not be such a bad thing after all :-) -- [1] Yes, that Loosmore; Ms GNU libc herself, along with being an OG GNU hacker, right from the start and an RMS buddy, she was also an editor of the CL spec. [2] http://www.cliki.net/css-lite http://www.cliki.net/css-lite
  - JoelMcCracken 16y ago
    As a lisper, I am ashamed that I did not know what parenscript was. I am very happy that you were able to correct that for me.
  - jbr 16y ago
    To plug my own project, I've also been developing a lisp dialect that compiles to JavaScript. I plan to announce on HN when the docs are complete. It's fully self-hosting, runs in the browser, and comes with a repl/compiler that runs on node. http://github.com/jbr/sibilant http://github.com/jbr/sibilant http://sibilantjs.info/ http://sibilantjs.info/
    - mahmud 16y ago
      That's some excellent work there my friend. I specially liked your Lisp/jQuery integration : http://github.com/jbr/sibilant/blob/master/public/javascripts/sibilant.info.lisp http://github.com/jbr/sibilant/blob/master/public/javascript...
Terhorst 16y ago
JS minimizers tend to remove all the newlines, so semicolons are often necessary if you use one.
- bruceboughton 16y ago
  Was going to say that this is clearly a bug in the minifier but then I thought about the effort involved in properly supporting non-terminated lines (or even detecting it). You're going to end up writing a JS parser. This really shows the cost of this syntactic nicety to the language.
  - wlievens 16y ago
    I would hope that minifiers use a JS parser!
    - bruceboughton 16y ago
      I imagine much of the minification could be done using just a lexer rather than a full parser. I'm quite probably wrong though.
- x5315 16y ago
  This just isn't true. The YUI minifier, for example, works perfectly fine without semicolons in the original. Equally, the Google Closure Compiler does also. If you're using a minifier that just removes new lines and suffers without semicolons, I think you should rethink your minifcation process.
technoweenie 16y ago
Client side - yes. Server side - no. Server side code typically only runs through one interpreter, and is never minimized.
emehrkay 16y ago
Just do what Doug Crockford says, that definitely includes braces
wlievens 16y ago
Yes, because JSLint tells me to do so, among other reasons.
deleted 16y ago
[deleted]
lhorie 16y ago
fwiw, I often see this var bla = function() { //stuff //more stuff //some more }//no semicolon
tszming 16y ago
Quote from Douglas Crockford (http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-the-good-parts%E2%80%9D-by-crockford http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-...): When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. I suppose it was a way of showing off ... Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes. Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?
esschul 16y ago
Never make the browser guess.
domnit 16y ago
It seems like semicolon insertion is an example of browsers being liberal acceptors of slop. Good that the rules are codified by ECMA, much like HTML5's error recovery parsing rules, but I wouldn't omit semicolons on purpose.
jasonkester 16y ago
Readability is the single most important quality of a piece of code. Semicolons aid readability by eliminating ambiguity and ensuring that nobody ever has to spend even a second figuring out whether your code will do what it looks like it will do. I add semicolons for the same reason I surround if blocks with braces, pad out blocks with whitespace, and avoid the ternary operator in all but the most trivial cases. If you ever find yourself dropped onto a line of my code by a debugger, chances are you'll be able to figure out exactly what's going on immediately. At least that's the goal. (more here: http://expatsoftware.com/articles/2007/06/getting-your-priorities-straight.html http://expatsoftware.com/articles/2007/06/getting-your-prior... )
- keefe 16y ago
  This is one of the hardest things to learn about software and why it's so nice to work with people with similar style. I always use semicolons in js. I love the ternary operator on short bits of code though. foo(something==null?somethingElse:something);
noodle 16y ago
yes, because the consistency removes it as a potential cause of bugs, and makes my code easier to debug by someone else.
mumrah 16y ago
Absolutely. Also, always use "var" in your variable declarations. I can't count how many times a scope issue bit me in the ass b/c of a missing "var"
- rchowe 16y ago
  Putting a single "use strict"; line at the top of a source file or function will turn on ECMAScript 5 strict mode for that scope, which will error on assigning a previously undeclared variable. I'm not sure if any browsers currently implement this though.
polotek 16y ago
I respectfully abstain from the vote.
x5315 16y ago
The case for semicolons within javascript is one that you will hear a lot. You'll hear many cries for 'readability', 'eliminating random bugs' and 'helping minification'. To begin with readability, i'm pretty sure that programmers are capable of working out the end of a line without the use of a semicolon: Scala has no such requirement of semicolons. Surely, the best way to ensure readability is, like in spoken language, to use common terms and expressions. Finding the obscure uses of the language to ensure the forceful requirement of a semicolon just seems petty and unhelpful. It is the equivalent of being overly prolix within a natural language, therefore limiting the ability to communicate. The elimination of random bugs is a little more tricky to discern. Sure, there are occasional issues that can be caused by the lack of semicolons, for example (taken from the quoted text): a = b + c (d + e).print() But let's face it, if you're writing your javascript like that then you probably need to re-evaluate the your use of (d + e). After all, the majority of browsers now use javascript compilers that are more than capable of constant folding. Therefore meaning that: a = b + c var f = d + e f.print() should therefore be no less efficient and, on the side of readability, you could even name f to be something worthwhile. The best minifiers (YUI and Google's Closure Compiler) are perfectly capable of minifying javascript without semicolons. If your minifier is having issues because you haven't inserted a semicolon, then—obviously—it's not doing its job properly. In my writing of javascript, I very rarely use semicolons and the issues described have never come up. Often the expressions given as to why it is necessary are extreme and obscure to the point whereby using those expressions may not be the best policy. I'm not advocating the idea of never using semicolons (something i pretty much do), I'm just saying that the requirement for constant use is pointless.
SubtleGradient 16y ago
Mind your own business! It's none of your business how I choose to code my own projects. If we're on the same project together, we can discuss it and decide on a style that works for everyone. When I contribute to an OpenSource project, I adopt whatever style they have defined. For my own projects, I have personally opted out of using unnecessary semicolons and brackets unless they improve maintainability or readability. But you don't have to know or care about that.
- TeHCrAzY 16y ago
  You were down-voted because of your tone, which came across as very rude; certainly an undesirable characteristic of posters.
  - deleted 16y ago
    [deleted]
IsaacSchlueter 16y ago
My comment on the subject: http://groups.google.com/group/nodejs/msg/de4630fa8953b183 http://groups.google.com/group/nodejs/msg/de4630fa8953b183
hcm 16y ago
Let Crockford himself explain why 'Yes' is the right answer: http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s

24 points by felixge 16y ago

felixge 16y ago

Personally I think the Google Javascript Style Guide has it right: > Relying on implicit insertion can cause subtle, hard to debug problems. Don't do it. You're better than that. http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Semicolons#Semicolons http://google-styleguide.googlecode.com/svn/trunk/javascript...

uptown 16y ago
Interesting that you use Google as the example for always using semi-colons with JavaScript. When writing a code-example on a white-board during my Google interview, I was using semi-colons throughout my code. One of the things the interviewer asked was why I was using semi-colons ... implying that my code wasn't as clean as it could be. We talked about whether they were needed or not, but his preference seemed to be that they weren't really necessary, and that I shouldn't have been including them in my code. I continue to use them in my code.
- yock 16y ago
  Perhaps your interviewer asked the question to see if you could justify them, thus gauging your understanding of how the language is parsed at runtime. The fact that the conversation continued may indicate that he or she wasn't convinced by your answer?
  - dazzawazza 16y ago
    I think this is more likely. When interviewing the point is to find out how someone is thinking not if they agree with a coding standard.
  - uptown 16y ago
    Quite possible. It wasn't a turning-point in the interview or anything ... but a discussion that lasted longer than I would have expected given the topic.
    - mrfish 16y ago
      Did you get the job?
felixge 16y ago
FWIW: I would like to not use semicolons in JS. But the current "push" for that is IMHO a mix of ruby/python home sickness and "Let's do this because we are smart enough to do it right.". Both are terrible influences on style in any language.
mathgladiator 16y ago
I once wrote a tool to beautify javascript from a mangled/compress form and in doing so learn that implicit insertion is absolute evil. return { a : true } and return { a : true } are different and can cause many problems.

jacquesm 16y ago

For me it's a 'yes' based on the simple rule that explicit is always better than implicit. That sort of 'optimisation' seems to be really cool when you're just starting out in a language but in the long run it isn't worth it. The first time you're bitten in the behind by a subtle bug after a couple of hours searching you've given up a hundredfold the time you have saved up to that point by not having to type those ;s. At that point people usually 'get it'.

KlausTrainer 16y ago
> For me it's a 'yes' based on the simple rule that explicit is always better than implicit. That sort of 'optimisation' seems to be really cool when you're just starting out in a language but in the long run it isn't worth it. I don't really get what you call implicit when you terminate statements with semicolons instead of linebreaks... ... Ok, I get what you're hinting it: there are some (very) few exceptions. However, I cannot see where there is any 'optimisation' in using linebreaks instead of semicolons. You better need to explain why someone should use both linebreaks _and_ semicolons, when only using linebreaks is actually as good as well. Basically, it's just a matter of style. Aside from a few exceptions (e.g. described in http://inimino.org/~inimino/blog/javascript_semicolons http://inimino.org/~inimino/blog/javascript_semicolons), linebreaks terminate a statement. If you stick with writing only one statement per line, I don't see what's so implicit with it. Rather terminating a statement both with a line break and a semicolon is a tautology, and hence introduces unnecessary redundancy. The actual question is, whether one can require that developers know the (maybe a handful) exceptions where a line break doesn't terminate a statement. I have decided (for myself) that I can require that knowledge, as it really comes down to only a few exceptions (that I believe are easy to remember). But, of course, I'm aware that one can also come do another reasonable conclusion. The only important thing is that people make a concious decision about the issue at all. The importance of this increases with the number of people that are working together on a particular project. Here a link to another article discussing that issue: http://mislav.uniqpath.com/2010/05/semicolons/ http://mislav.uniqpath.com/2010/05/semicolons/
- jasonkester 16y ago
  But linebreaks don't terminate statements in javascript. x = y /* TODO: clean this up to make it more readable * and maybe add some semicolons */ + 4 ... is a single statement.

deleted 16y ago

[deleted]

troels 16y ago

When the curly-braces-syntax is replaced with proper sexp, I'm all for it. Until then, I prefer to keep the semicolons.

mahmud 16y ago
Parenscript; the happy amalgamation of Common Lisp and JavaScript, in your server or your browser. http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/ People are writing Node.js code in it :-) http://tryparenscript.com/ http://tryparenscript.com/ It reminds me of an old Scheme dialect, implemented in Common Lisp, and was used to implement the Yale Haskell compiler (by Sandra Loosemore[1], et al.); it's just one of those baroque language towers that you're not sure how it works, but somehow works perfectly. Combine parenscript with CSS-Lite[2] and you enter a weird world of web development in 100% Lisp (not entirely good though; you wont be able to cut-and-paste stuff from SO, but then, thinking for yourself might not be such a bad thing after all :-) -- [1] Yes, that Loosmore; Ms GNU libc herself, along with being an OG GNU hacker, right from the start and an RMS buddy, she was also an editor of the CL spec. [2] http://www.cliki.net/css-lite http://www.cliki.net/css-lite
- JoelMcCracken 16y ago
  As a lisper, I am ashamed that I did not know what parenscript was. I am very happy that you were able to correct that for me.
- jbr 16y ago
  To plug my own project, I've also been developing a lisp dialect that compiles to JavaScript. I plan to announce on HN when the docs are complete. It's fully self-hosting, runs in the browser, and comes with a repl/compiler that runs on node. http://github.com/jbr/sibilant http://github.com/jbr/sibilant http://sibilantjs.info/ http://sibilantjs.info/
  - mahmud 16y ago
    That's some excellent work there my friend. I specially liked your Lisp/jQuery integration : http://github.com/jbr/sibilant/blob/master/public/javascripts/sibilant.info.lisp http://github.com/jbr/sibilant/blob/master/public/javascript...

Terhorst 16y ago

JS minimizers tend to remove all the newlines, so semicolons are often necessary if you use one.

bruceboughton 16y ago
Was going to say that this is clearly a bug in the minifier but then I thought about the effort involved in properly supporting non-terminated lines (or even detecting it). You're going to end up writing a JS parser. This really shows the cost of this syntactic nicety to the language.
- wlievens 16y ago
  I would hope that minifiers use a JS parser!
  - bruceboughton 16y ago
    I imagine much of the minification could be done using just a lexer rather than a full parser. I'm quite probably wrong though.
x5315 16y ago
This just isn't true. The YUI minifier, for example, works perfectly fine without semicolons in the original. Equally, the Google Closure Compiler does also. If you're using a minifier that just removes new lines and suffers without semicolons, I think you should rethink your minifcation process.

technoweenie 16y ago

Client side - yes. Server side - no. Server side code typically only runs through one interpreter, and is never minimized.

emehrkay 16y ago

Just do what Doug Crockford says, that definitely includes braces

wlievens 16y ago

Yes, because JSLint tells me to do so, among other reasons.

deleted 16y ago

[deleted]

lhorie 16y ago

fwiw, I often see this var bla = function() { //stuff //more stuff //some more }//no semicolon

tszming 16y ago

Quote from Douglas Crockford (http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-the-good-parts%E2%80%9D-by-crockford http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-...): When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. I suppose it was a way of showing off ... Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes. Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?

esschul 16y ago

Never make the browser guess.

domnit 16y ago

It seems like semicolon insertion is an example of browsers being liberal acceptors of slop. Good that the rules are codified by ECMA, much like HTML5's error recovery parsing rules, but I wouldn't omit semicolons on purpose.

jasonkester 16y ago

Readability is the single most important quality of a piece of code. Semicolons aid readability by eliminating ambiguity and ensuring that nobody ever has to spend even a second figuring out whether your code will do what it looks like it will do. I add semicolons for the same reason I surround if blocks with braces, pad out blocks with whitespace, and avoid the ternary operator in all but the most trivial cases. If you ever find yourself dropped onto a line of my code by a debugger, chances are you'll be able to figure out exactly what's going on immediately. At least that's the goal. (more here: http://expatsoftware.com/articles/2007/06/getting-your-priorities-straight.html http://expatsoftware.com/articles/2007/06/getting-your-prior... )

keefe 16y ago
This is one of the hardest things to learn about software and why it's so nice to work with people with similar style. I always use semicolons in js. I love the ternary operator on short bits of code though. foo(something==null?somethingElse:something);

noodle 16y ago

yes, because the consistency removes it as a potential cause of bugs, and makes my code easier to debug by someone else.

mumrah 16y ago

Absolutely. Also, always use "var" in your variable declarations. I can't count how many times a scope issue bit me in the ass b/c of a missing "var"

rchowe 16y ago
Putting a single "use strict"; line at the top of a source file or function will turn on ECMAScript 5 strict mode for that scope, which will error on assigning a previously undeclared variable. I'm not sure if any browsers currently implement this though.

polotek 16y ago

I respectfully abstain from the vote.

x5315 16y ago

The case for semicolons within javascript is one that you will hear a lot. You'll hear many cries for 'readability', 'eliminating random bugs' and 'helping minification'. To begin with readability, i'm pretty sure that programmers are capable of working out the end of a line without the use of a semicolon: Scala has no such requirement of semicolons. Surely, the best way to ensure readability is, like in spoken language, to use common terms and expressions. Finding the obscure uses of the language to ensure the forceful requirement of a semicolon just seems petty and unhelpful. It is the equivalent of being overly prolix within a natural language, therefore limiting the ability to communicate. The elimination of random bugs is a little more tricky to discern. Sure, there are occasional issues that can be caused by the lack of semicolons, for example (taken from the quoted text): a = b + c (d + e).print() But let's face it, if you're writing your javascript like that then you probably need to re-evaluate the your use of (d + e). After all, the majority of browsers now use javascript compilers that are more than capable of constant folding. Therefore meaning that: a = b + c var f = d + e f.print() should therefore be no less efficient and, on the side of readability, you could even name f to be something worthwhile. The best minifiers (YUI and Google's Closure Compiler) are perfectly capable of minifying javascript without semicolons. If your minifier is having issues because you haven't inserted a semicolon, then—obviously—it's not doing its job properly. In my writing of javascript, I very rarely use semicolons and the issues described have never come up. Often the expressions given as to why it is necessary are extreme and obscure to the point whereby using those expressions may not be the best policy. I'm not advocating the idea of never using semicolons (something i pretty much do), I'm just saying that the requirement for constant use is pointless.

SubtleGradient 16y ago

Mind your own business! It's none of your business how I choose to code my own projects. If we're on the same project together, we can discuss it and decide on a style that works for everyone. When I contribute to an OpenSource project, I adopt whatever style they have defined. For my own projects, I have personally opted out of using unnecessary semicolons and brackets unless they improve maintainability or readability. But you don't have to know or care about that.

TeHCrAzY 16y ago
You were down-voted because of your tone, which came across as very rude; certainly an undesirable characteristic of posters.
- deleted 16y ago
  [deleted]

IsaacSchlueter 16y ago

My comment on the subject: http://groups.google.com/group/nodejs/msg/de4630fa8953b183 http://groups.google.com/group/nodejs/msg/de4630fa8953b183

hcm 16y ago

Let Crockford himself explain why 'Yes' is the right answer: http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s