Hacker News new | past | comments | ask | show | jobs | submit login
Poll: Semicolons in JavaScript
24 points by felixge on July 26, 2010 | hide | past | favorite | 39 comments
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

Yes
413 points
No
44 points



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/javascript...


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.


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.


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?


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.


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.


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.


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-prior... )


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);


Quote from Douglas 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?


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'.


> 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), 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/


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.


It's funny how people will take an assumption and keep it without ever verifying if that assumption really holds.

This is a really nice example of that.

It also is reminiscent of one of my favourite programming jokes:

   int x;
   int y;

   x = 0; /* initialise both x 
   y = 0;    and y to 0 */


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


Parenscript; the happy amalgamation of Common Lisp and JavaScript, in your server or your browser.

http://common-lisp.net/project/parenscript/

People are writing Node.js code in it :-)

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


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://sibilantjs.info/


That's some excellent work there my friend. I specially liked your Lisp/jQuery integration : http://github.com/jbr/sibilant/blob/master/public/javascript...


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.


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


fwiw, I often see this

  var bla = function() {
    //stuff
    //more stuff
    //some more
  }//no semicolon


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"


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.


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


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


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.


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.


I would hope that minifiers use a JS parser!


I imagine much of the minification could be done using just a lexer rather than a full parser. I'm quite probably wrong though.


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.


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.


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


My comment on the subject:

http://groups.google.com/group/nodejs/msg/de4630fa8953b183


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


Never make the browser guess.


Just do what Doug Crockford says, that definitely includes braces


I respectfully abstain from the vote.


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.


You were down-voted because of your tone, which came across as very rude; certainly an undesirable characteristic of posters.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: