I think that issacs is missing the part where other people try to read his code. We put semicolons at the end of each statement, even though it's shorter to leave them out, because it's how JavaScript is written, and how others are comfortable reading it. We spell English correctly, even though it's full of meddlesome "ou"s and "gh"s, because that's the way English is spelled. In fact, issacs' proposed semicolon-less, comma-first style reminds me of Mark Twain's "Plan for the Improvement of English Spelling":
For example, in Year 1 that useless letter c would be dropped to
be replased either by k or s, and likewise x would no longer be
part of the alphabet. The only kase in which c would be retained
would be the ch formation, which will be dealt with later.
Year 2 might reform w spelling, so that which and one would take
the same konsonant, wile Year 3 might well abolish y replasing it
with i and Iear 4 might fiks the g/j anomali wonse and for all.
Jenerally, then, the improvement would kontinue iear bai iear
with Iear 5 doing awai with useless double konsonants, and Iears
6-12 or so modifaiing vowlz and the rimeining voist and unvoist
konsonants.
Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi
ridandant letez c, y and x — bai now jast a memori in the maindz
ov ould doderez — tu riplais ch, sh, and th rispektivli.
Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev
a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.
For example, in Year 1 that useless letter c would be dropped to
be replased either by k or s, and likewise x would no longer be
part of the alphabet. The only case in which c would be retained
would be the ch formation, which will be dealt with later.
Year 2 might reform w spelling, so that which and one would take
the same consonant, while Year 3 might well abolish y replacing it
with i and Year 4 might fix the g/j anomaly wronse and for all.
Generally, then, the improvement would continue year by year
with Year 5 doing away with useless double consonants, and Years
6-12 or so modifying vowels and the remaining voiced and unvoiced
consonants.
By Year 15 or so, it would finally be possible to make ius of thi
redundant letters c, y and x — by now just a memory in the minds
of ould doderez — to replace ch, sh, and th respectively.
Finally, then, after some 20 years of orxogrefcl reform, we would have
a logical, cohernt spelling in ius xrewawt the English-speaking world.
npm is a hobby project designed to bring me joy. As a side-effect, a lot of node users find it helpful. That's great, and I'm proud, but honestly, if everyone stopped using it, I'd keep hacking on it.
A little boy may grow up to be the doctor who cures cancer. But that's not why you have children.
For me the reason to always use semicolons is the same reason I always use ===. There are just too many rules to remember and I've got more important things to keep in my mind.
It's also good to have your JavaScript look like the JavaScript most other people write. I have practiced many different coding conventions in my life, and I don't really hate none of them, but the thing I do dislike is context-switching between different conventions in different projects. We already have tabs v/s spaces and several other possible differences. It would be nice to exclude the choice for semicolon placement from that list.
I do agree with the author in one point: you should understand how automatic semicolon insertion works. And then make up your mind about it. Don't just blindly follow anybodys advice.
I think this is the most important point: if understanding when or when not to use semicolons requires a subtle understanding of the language grammar, then terminating every statement has a cognitive cost. This cost adds to coding friction.
I don't personally use JS, but I do use C/C++ and Python. I prefer Python's syntax because I find it clean. Most of my work is in semicolon-and-brace languages, so I'm clearly familiar with that style, too. But were I to code in JS, I'd always use semicolons, because that's easier than constantly asking myself, "Do I need a semicolon or not?"
As an analogy, I use my turn signal every time I make a turn in my car. Every time. Even if I'm in an empty parking lot. That way, I never have to decide, "Should I use my turn signal?" It's just automatic. It reduces the amount of thought I have to put into things that don't actually matter.
"One of the mistakes in the language is semicolon insertion. This is a technique for making semicolons optional as statement terminators. It is reasonable for IDEs and shell programs to do semicolon insertion. It is not reasonable for the language definition to require compilers to do it. Use semicolons."
I'm inclined to agree. You already have to deal with enough complexity while you're programming, why add more? It's easier to follow the rule 'always use semicolons' than to try to selectively use them.
The counter to that argument is "You already have to deal with enough visual noise while you're programming, why add more?". Semi-colon insertion rules aren't that complicated. To me, it's a matter of what style project participants are comfortable with.
Because JavaScript allows semicolon insertion some syntax is parsed in a way which is surprising to those skilled with other curly brace languages. This can causes problems if you do or don't try to leave out semicolons.
The solution to avoiding unexpected behavior is to run JSLint. JSLint will insist that you use semicolons. So you will have to use semicolons.
Since my http://eloquentjavascript.net recommends always terminating statements with semicolons, I guess I'm being directly addressed by this.
The suggestion that 'I don't understand semicolon insertion' doesn't really hit the mark. I wrote a JavaScript implementation.
Yet still I recommend everyone to use explicit semicolons. Going over the proposed style on this page, it all sounds pretty good, and semicolon insertion is starting to look okay. Until you realize that he wants you to start every line that starts with [(+/-,.* with a semicolon. This is needed to prevent semicolon insertion from failing you.
I'm sure one can get used to such a style, but it is completely 'out there', radically disconnected from JavaScript's C parentage, and, though that's a question of taste, ugly and irregular. This solution is worse than the problem, I think.
I don't mind you telling people to end lines with semicolons.
I'd mind it if you told people that omitting semicolons causes cancer. (Or bugs.)
--
EDIT:
I just looked up your book to the point where you make this recommendation. You don't threaten any catastrophes, which is good. I disagree with the "complex and weird" conclusion, but it's certainly a valid decision to leave them out of the book if you'd rather not go into it.
We programmers have a tendency to focus our arguments about code almost entirely from the perspective of code creation rather than maintenance, and I think that's in part what this article does.
An experienced coder who knows how Javascript works is unlikely to create problematic code even without semicolons, but it's fairly easy to imagine how errors could be introduced as a large, complex program is maintained by multiple developers, some of them potentially less experienced than the author. Like conditional braces in C, Javascript's semicolons are an optional syntax that can be used to make code more foolproof, and therefore more maintainable - though perhaps at the expense of some programmers' aesthetic preferences.
Really, though, I find most arguments about syntax aesthetics annoying, especially when people get their passions so inflamed over presentation rather than meaning that they have to risk "insulting" people. The stakes are so small. And if what you believe is so important, wouldn't it be better to convince people rather than intentionally alienate them?
People usually think there's a 1 to 1 correlation between "I like this" and "this is objectively good" and then spend a lot of time trying to logically justify their tastes. But taste doesn't really work that way - otherwise how else can you explain the popularity of Britney Spears?
I have my own tastes about how to write code in the languages I use, but I recognize that those preferences are generally just that - matters of taste - and tend not to try forcing them on others.
I agree, but I would like to quote the author : "This isn’t an article where I try to convince you to write your code like I write mine."
He does not really try to force his style.
I respect his approach, because even if the article seems to be about aesthetic preferences, I think that he is concerned by the lack of curiosity and education that may be shown by some programmers. I think what the author really says is : RTFM. None of the comments here focus on the conclusion of the article, which is the most important part:
"Cozy up with some hot chocolate and the ECMAScript spec some Saturday afternoon. Practice a little. Play around with some test programs. It’s a good time.
Or don’t do that, if you don’t feel like it. It’s your life. You almost certainly have better things to do with it.
Just please stop making authoritative claims like “terminate all lines with semicolons to be safe.” It’s not any safer, or more reliable."
The author doesn’t seem to work in a team where the code is going to be touched by multiple people, all with varying levels of competence. It’s easy to explain to your colleagues that JS should have semi-colons added or weirdness can happen. It’s less easy to say ”Here’s the ECMAScript spec, go read it“ when they’ve got ruby and HTML and CSS and SQL to write and simply don’t have the time to thoroughly master each and every part of the stack.
The point is that always adding semicolons does not solve the weirdness problem. Consider:
return
17
This returns undefined, which is counter-intuitive if you come from other c-style syntax languages. But if you say "always terminate statements with a semicolons, otherwise weirdness happens", the intuitive fix is:
return
17;
Which still doesn't solve the problem. You have to remember an additional rule: "Don't insert line breaks in the middle of a statement, if the line break could be interpreted as a statement terminator." Or to put it another way: If you are in doubt, don't use a line break.
The problem isn't really if statements should be terminated with a semicolon or not. The problem is to decide when it is safe to insert a line break when it is not intended to terminate the statement.
He used to work at Yahoo. That's where I met him and while I never worked on a team with him, he seemed like a nice guy. Definitely smart, though his blog/writing style may come across as arrogant to some. I would have loved to end up on a team with him as I'm sure I could have learned a lot from him.
While there may be nothing technically wrong with Isaac's style, and it may in fact be slightly "better" in some way, it's clearly not how the language was intended to be written or how the vast majority of people write it.
I would be ok with leaving the semicolons off, if you didn't have to do ridiculous things like prepend some lines with semicolons instead. It's easier for everyone just to put the damn semicolons in.
I couldn't care less what your pants policy is in your own home, as long as I never come over. But when you invite me over (i.e. open source a project) and you have a ridiculous pants policy don't expect me to come back.
I would be ok with leaving the semicolons off, if you didn't have to do ridiculous things like prepend some lines with semicolons instead. It's easier for everyone just to put the damn semicolons in.
It'd be nice if I had a linter to catch things like this. But really, it's not so hard to spot. I was bitten by missing semis often enough to start prepending [ and ( already, before I started just leaving them out entirely.
No one's going to cry if you don't contribute to npm. When I contribute to your project, I'll follow whatever style you like, and if I find it to onerous, I'll move on. Life is tradeoffs.
I do not like inconsistency. I never leave out curly braces. I never omit semi-colons. There is no reason to do so.
I dislike working on code written by people who feel the need to omit these symbols. I would prefer if JavaScript would, like PHP or C, require semicolons at the end of every statement.
Be very, very careful when you're using PHP as an example of the proper way to do something, because you're probably at least partially wrong. Semicolons are optional when followed by a closing tag (and likewise, closing tags are optional when the last statement ends with a semicolon -- in this case, whitespace at the end of the file is valid, as well)
JSLINT will catch basically all of these problems for you automatically, with it you don't have to worry about improperly parsed code, semi-colon insertion, ==, for in, the stupid constructors like new Function and new Object, implied globals, or most of the crap in the language.
There are still some deep problems with JavaScript that no tool, not even JSLINT can fix, like the fact that the language uses + for both concatenation and addition, there is no namespaces, there is no way to create immutable objects, etc.
I recommend you use a good IDE (like Eclipse) and hook it up with JSLINT so that you can ensure that you don't ever accidentally create global variables or create statements that the parser doesn't understand.
I honestly never thought that much about the use of semicolons vs not.
I'm not a hardcore JS programmer, I know enough to get paid for it, and I'm the best JS programmer of my current employer. But I'm far from a jedi master.
Isn't this just a matter of personal preference? A semi-colon is interchangable with \n as long as you use it following the same rules. Which I do because I treat it as a visual marker for the end of a statement.
The counter argument is why use it if the system already recognizes the \n in place there, for which I say to make it easier for other JS programmers to recognize and parse since the \n is used in other places where it isn't the end of a line.
I guess I don't really see this as a compelling argument being made here, or I've misunderstood what is being argued.
Most of the controversy stems from the fact that Doug Crockford, widely regarded as the javascript expert, has been aggressively saying "Use semicolons at the end of every statement or you will be miserable" for years, particularly in his influential book "Javascript - the Good Parts." You can see a presentation where he reiterates this point, among others, here: http://www.youtube.com/watch?v=hQVTIJBZook
This blogger has a pretty compelling argument against this view.
Just because the rule exists doesn't mean it's the right thing to do.
Adding oddities to a language that could be small and simple creates these ongoing controversies. What are PHP developers _still_ talking about? SQL injection. What are Rails developers _still_ talking about? How to use REST properly. What are JavaScript developers _still_ talking about? Semicolon's or not.
This all points to poor design decisions in my mind. And we're at a loss to change the language unless we do something like CoffeeScript.
I think the reasons a lot of people use semicolons is that it's just easier. Also if you come from a language that enforces them, it's natural just to use them. That's why I use them anyway.
I completely agree. I really don't care how anyone writes their code. I care about self-described experts giving false information about the language to newcomers.
If there is pedantry, it is about the importance of either telling the truth or shutting up.
[+] [-] jashkenas|15 years ago|reply
[+] [-] woodall|15 years ago|reply
[+] [-] IsaacSchlueter|15 years ago|reply
A little boy may grow up to be the doctor who cures cancer. But that's not why you have children.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] nene|15 years ago|reply
It's also good to have your JavaScript look like the JavaScript most other people write. I have practiced many different coding conventions in my life, and I don't really hate none of them, but the thing I do dislike is context-switching between different conventions in different projects. We already have tabs v/s spaces and several other possible differences. It would be nice to exclude the choice for semicolon placement from that list.
I do agree with the author in one point: you should understand how automatic semicolon insertion works. And then make up your mind about it. Don't just blindly follow anybodys advice.
[+] [-] scott_s|15 years ago|reply
I don't personally use JS, but I do use C/C++ and Python. I prefer Python's syntax because I find it clean. Most of my work is in semicolon-and-brace languages, so I'm clearly familiar with that style, too. But were I to code in JS, I'd always use semicolons, because that's easier than constantly asking myself, "Do I need a semicolon or not?"
As an analogy, I use my turn signal every time I make a turn in my car. Every time. Even if I'm in an empty parking lot. That way, I never have to decide, "Should I use my turn signal?" It's just automatic. It reduces the amount of thought I have to put into things that don't actually matter.
[+] [-] mistermann|15 years ago|reply
[+] [-] davidsiems|15 years ago|reply
"One of the mistakes in the language is semicolon insertion. This is a technique for making semicolons optional as statement terminators. It is reasonable for IDEs and shell programs to do semicolon insertion. It is not reasonable for the language definition to require compilers to do it. Use semicolons."
http://javascript.crockford.com/survey.html
I'm inclined to agree. You already have to deal with enough complexity while you're programming, why add more? It's easier to follow the rule 'always use semicolons' than to try to selectively use them.
[+] [-] mcantelon|15 years ago|reply
[+] [-] artsrc|15 years ago|reply
Because JavaScript allows semicolon insertion some syntax is parsed in a way which is surprising to those skilled with other curly brace languages. This can causes problems if you do or don't try to leave out semicolons.
The solution to avoiding unexpected behavior is to run JSLint. JSLint will insist that you use semicolons. So you will have to use semicolons.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] marijn|15 years ago|reply
The suggestion that 'I don't understand semicolon insertion' doesn't really hit the mark. I wrote a JavaScript implementation.
Yet still I recommend everyone to use explicit semicolons. Going over the proposed style on this page, it all sounds pretty good, and semicolon insertion is starting to look okay. Until you realize that he wants you to start every line that starts with [(+/-,.* with a semicolon. This is needed to prevent semicolon insertion from failing you.
I'm sure one can get used to such a style, but it is completely 'out there', radically disconnected from JavaScript's C parentage, and, though that's a question of taste, ugly and irregular. This solution is worse than the problem, I think.
[+] [-] IsaacSchlueter|15 years ago|reply
I'd mind it if you told people that omitting semicolons causes cancer. (Or bugs.)
-- EDIT:
I just looked up your book to the point where you make this recommendation. You don't threaten any catastrophes, which is good. I disagree with the "complex and weird" conclusion, but it's certainly a valid decision to leave them out of the book if you'd rather not go into it.
My opinion of you: Not Evil. <3
[+] [-] quag|15 years ago|reply
Good point, that isn't immediately clear.
To help me understand, the article listed an example where a line started with a [, what are situations where a line is likely to start with (+/-,.* ?
[+] [-] compay|15 years ago|reply
An experienced coder who knows how Javascript works is unlikely to create problematic code even without semicolons, but it's fairly easy to imagine how errors could be introduced as a large, complex program is maintained by multiple developers, some of them potentially less experienced than the author. Like conditional braces in C, Javascript's semicolons are an optional syntax that can be used to make code more foolproof, and therefore more maintainable - though perhaps at the expense of some programmers' aesthetic preferences.
Really, though, I find most arguments about syntax aesthetics annoying, especially when people get their passions so inflamed over presentation rather than meaning that they have to risk "insulting" people. The stakes are so small. And if what you believe is so important, wouldn't it be better to convince people rather than intentionally alienate them?
People usually think there's a 1 to 1 correlation between "I like this" and "this is objectively good" and then spend a lot of time trying to logically justify their tastes. But taste doesn't really work that way - otherwise how else can you explain the popularity of Britney Spears?
I have my own tastes about how to write code in the languages I use, but I recognize that those preferences are generally just that - matters of taste - and tend not to try forcing them on others.
[+] [-] peti|15 years ago|reply
"Cozy up with some hot chocolate and the ECMAScript spec some Saturday afternoon. Practice a little. Play around with some test programs. It’s a good time. Or don’t do that, if you don’t feel like it. It’s your life. You almost certainly have better things to do with it. Just please stop making authoritative claims like “terminate all lines with semicolons to be safe.” It’s not any safer, or more reliable."
[+] [-] robin_reala|15 years ago|reply
[+] [-] olavk|15 years ago|reply
The problem isn't really if statements should be terminated with a semicolon or not. The problem is to decide when it is safe to insert a line break when it is not intended to terminate the statement.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] cancelbubble|15 years ago|reply
[+] [-] tlrobinson|15 years ago|reply
I would be ok with leaving the semicolons off, if you didn't have to do ridiculous things like prepend some lines with semicolons instead. It's easier for everyone just to put the damn semicolons in.
I couldn't care less what your pants policy is in your own home, as long as I never come over. But when you invite me over (i.e. open source a project) and you have a ridiculous pants policy don't expect me to come back.
[+] [-] IsaacSchlueter|15 years ago|reply
It'd be nice if I had a linter to catch things like this. But really, it's not so hard to spot. I was bitten by missing semis often enough to start prepending [ and ( already, before I started just leaving them out entirely.
No one's going to cry if you don't contribute to npm. When I contribute to your project, I'll follow whatever style you like, and if I find it to onerous, I'll move on. Life is tradeoffs.
[+] [-] code_duck|15 years ago|reply
I dislike working on code written by people who feel the need to omit these symbols. I would prefer if JavaScript would, like PHP or C, require semicolons at the end of every statement.
[+] [-] parkan|15 years ago|reply
[+] [-] ScottBurson|15 years ago|reply
Seriously -- look at the complexity of these rules, and then tell me that Lisp's parentheses are worse.
[+] [-] ShardPhoenix|15 years ago|reply
[+] [-] jhuni|15 years ago|reply
There are still some deep problems with JavaScript that no tool, not even JSLINT can fix, like the fact that the language uses + for both concatenation and addition, there is no namespaces, there is no way to create immutable objects, etc.
I recommend you use a good IDE (like Eclipse) and hook it up with JSLINT so that you can ensure that you don't ever accidentally create global variables or create statements that the parser doesn't understand.
http://www.rockstarapps.com/joomla-1.5.8/products/jslint-ecl...
[+] [-] mrchess|15 years ago|reply
[+] [-] epochwolf|15 years ago|reply
[+] [-] IsaacSchlueter|15 years ago|reply
Mr. Chess, I both admire and fear the potency of your absurdism. I would compliment you further, but I am too afraid.
[+] [-] trickjarrett|15 years ago|reply
I'm not a hardcore JS programmer, I know enough to get paid for it, and I'm the best JS programmer of my current employer. But I'm far from a jedi master.
Isn't this just a matter of personal preference? A semi-colon is interchangable with \n as long as you use it following the same rules. Which I do because I treat it as a visual marker for the end of a statement.
The counter argument is why use it if the system already recognizes the \n in place there, for which I say to make it easier for other JS programmers to recognize and parse since the \n is used in other places where it isn't the end of a line.
I guess I don't really see this as a compelling argument being made here, or I've misunderstood what is being argued.
[+] [-] JonnieCache|15 years ago|reply
This blogger has a pretty compelling argument against this view.
[+] [-] axod|15 years ago|reply
[+] [-] ryan-allen|15 years ago|reply
Adding oddities to a language that could be small and simple creates these ongoing controversies. What are PHP developers _still_ talking about? SQL injection. What are Rails developers _still_ talking about? How to use REST properly. What are JavaScript developers _still_ talking about? Semicolon's or not.
This all points to poor design decisions in my mind. And we're at a loss to change the language unless we do something like CoffeeScript.
[+] [-] reid|15 years ago|reply
[+] [-] TamDenholm|15 years ago|reply
[+] [-] richtaur|15 years ago|reply
[+] [-] IsaacSchlueter|15 years ago|reply
If there is pedantry, it is about the importance of either telling the truth or shutting up.