Live data from Hacker News

Poll: Semicolons in JavaScript

news.ycombinator.com

31–40 of 44 posts

Re: Poll: Semicolons in JavaScript

#32
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.

Re: Poll: Semicolons in JavaScript

#33

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…

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

Re: Poll: Semicolons in JavaScript

#34
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.

Re: Poll: Semicolons in JavaScript

#35
post #9
post #5

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 yo…

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/

Re: Poll: Semicolons in JavaScript

#36
post #20
post #14

Earlier quoted context omitted.

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.

Did you get the job?

Re: Poll: Semicolons in JavaScript

#38

Earlier quoted context omitted.

> 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. How…

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 */

Re: Poll: Semicolons in JavaScript

#40
post #2

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

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.

Post reply on HN