
An Open Letter to JavaScript Leaders Regarding Semicolons - tswicegood
http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
======
jashkenas
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.

~~~
woodall
Sorry, had to try:

    
    
        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.

~~~
chc
Oddly, I found that mostly readable, though there were a few implicit changes
that he failed to spell out, so you need to infer those.

~~~
jerf
Of all the satire I have ever read, that may very well be the best, because to
this day I am _still_ not sure of the exact proportion of joke vs.
seriousness. And I've read my Twain, so it's not unfamiliarity with the
author. That's the mark of a truly masterful satire.

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

~~~
mistermann
Maybe an inappropriate question, but could you explain the significance of ===
to the unenlightened amongst us?

~~~
adolph
_The standard equality operators (== and !=) compare two operands without
regard to their type. The strict equality operators (=== and !==) perform
equality comparisons on operands of the same type. Use strict equality
operators if the operands must be of a specific type as well as value or if
the exact type of the operands is important. Otherwise, use the standard
equality operators, which allow you to compare the identity of two operands
even if they are not of the same type._

So: (1 == '1') is true;(1 === '1') is false.

[https://developer.mozilla.org/en/JavaScript/Reference/Operat...](https://developer.mozilla.org/en/JavaScript/Reference/Operators/Comparison_Operators)

~~~
Groxx
And, strangely, (NaN === NaN) is false. Gotta use isNaN(NaN).

~~~
raganwald
That's the only part of Javascript's ==/=== dichotomy that I like. It maps
directly to the way NULL works in SQL. NULL means "I don't know what this is,"
so two unknown things can't be tested for equality because you don't know what
they are. NaN is a similar concept. You tried to make a number, it borked, how
can you test one bork against another for equality?

~~~
Groxx
I hadn't thought of it that way (comparing borks, not sql null); it does make
some sense in that light (though then you _should_ be able to compare the same
NaN in two variables...).

Though that undefined === undefined works, and so does Infinity === Infinity
doesn't make as much sense when thought of that way; infinities aren't all
equal, and undefined isn't a single kind of _value_ that it makes sense to
compare as if it were. And to counteract the sql null viewpoint, (null ===
null) works.

Also:

    
    
      var x = parseInt("a");
      x === NaN // false
      alert(x); // "NaN"
    

doesn't make a whole lot of sense. isNaN() performs the _exact_ same thing
that === NaN implies. Especially as:

    
    
      {}.x // undefined
      {x:undefined}.x // undefined
      for(prop in {x:undefined}) alert(prop); // displays "x"
      {}.x === {x:undefined}.x // true
    

Meh. It's a weird language. Not intending to shoot you down; just spilling my
brain into a textbox.

------
davidsiems
Here's what Crockford has to say on the subject:

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

~~~
rimantas
Rules may not be complicated. Seeing where and how they should be applied in
the sea of code, some you did not write—entirely different story.

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

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

My opinion of you: Not Evil. <3

~~~
Roboprog
Finally, somebody else who hates the largely gratuitous semicolons.

Example: <http://roboprogs.com/devel/2010.06.html>

It's a shame they didn't just make it fully line oriented (like BASIC, xBASE,
shell-script, Python, Ruby, ...), with the customary backslash or ampersand to
indicate an incomplete line. (but they didn't) I guess then Netscape would
have had to call it FooScript (or something silly like echhh-muh-script).

The worst thing I hate about the "add semicolons!" religion is that it teaches
people not to spot statements that are going to be terminated by a newline. So
then, I have to see all the extra noise on each line :-(

Don't people test the crap they write?!?

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

~~~
peti
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._ "

~~~
mattmanser
Some programmers like to know everything about a language they are using,
knowing all the edge cases, keywords no-one else uses, the exact execution
order of tokens and weird quirks. They are masters of complete understanding,
and very occasionally this mastery allows them to come up with a revolution in
the way things are done. Let's call these the Scholars.

A lot of others don't though, the joy of programming for them is not mastery
of the grammar but writing the story. They would rather use a combination of
run it and see and diving into the documentation only when totally necessary.
Do not mistake this for an amateur who is cargo culting their code, these
programmers know exactly what their code does, they just learn the bits they
need as they need them. Let's call these the Mavericks.

I struggled to find neutral words for both schools of thought, don't read too
much into the names I picked.

Both types can be excellent hackers. And of course we have a spectrum in
between Scholars and Mavericks.

I am a Maverick. I find the Scholars, with their memorization of all the
rules, to be both awe inspiring and entirely tiresome at the same time. I
don't enjoy sitting down with a cocoa and a spec because I'd prefer to be
programming. There is a vast swathe of every spec and every library that is
entirely useless for the task I have at hand, quite often for any task I would
ever do. I see anything which forces me to learn that useless knowledge as a
waste of time.

Use semi-colons for every statement is a simple and easily remembered rule,
one which takes no effort compared to reading a spec that delivers me little
or even no benefit. I will also tend to forget these rules because my mind
just doesn't see it as particularly useful information, I don't use it enough.
I don't have any motivation to force that knowledge in my brain through
learning practices because to a Maverick, it's boring.

There is no lack of curiosity or education in the latter type of programmer. I
read this type of article which Scholars so often write with exasperation.
Mavericks just don't care about learning the intricacies of language grammar
compared to doing something else in programming. That something else is just
as intellectually demanding.

Please remember that the next time you come across a Maverick, we're just of
different schools, not of different ability.

~~~
IsaacSchlueter
If you are a Maverick, then that's fine. Write code however you like.
Seriously, I care less than anyone.

Just stop talking trash about how _I_ do things. If the story is more
interesting than the grammar, then shut up about grammar and go back to
writing stories.

My problem is with _telling people that there is a problem when there is no
problem_ , and at the same time calling yourself a scholar.

~~~
mattmanser
_If you don’t understand how statements in JavaScript are terminated, then you
just don’t know JavaScript very well, and shouldn’t write JavaScript programs
professionally without supervision_

You obviously do care to such an extent that you're saying that we shouldn't
even be programming without you looking over our shoulder.

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

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

~~~
gcr
Whoever linebreaks return statements like that deserves what's coming to them.

But I get what you're saying. Simple, consistent rules are better for
teamwork.

~~~
pdw
I do that sometimes (obviously not in JavaScript), to split up long lines in
situations such as this:

    
    
      bool is_foo_possible() {
        return
          test_first_condition() &&
          test_second_contition() &&
          test_third_condition()
      }
    

I don't think that's very horrible.

~~~
BrandonM
I would tend to write that:

    
    
      bool is_foo_possible() {
        return test_first_condition()
          && test_second_contition()
          && test_third_condition()
      }
    

I prefer to put my infix operators at the beginning of continuation lines,
because that makes it immediately clear from a glance that it's a continuation
line.

~~~
IsaacSchlueter
I do this as well.

For a while, I tried to stick to the rule that "return\n" was not allowed.
When I meant to return undefined, I'd write "return undefined".

In the end, I abandoned that rule, because too many of my functions return
undefined. But it's kind of a nice thing. When I do get around to building
that linter, I might make `return\s*\n` verboten.

~~~
olavk
You could just write "return;", that would make it obvious that no value is
returned.

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

~~~
IsaacSchlueter
_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.

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

~~~
parkan
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)

~~~
code_duck
Yes. There is one situation in which you may omit a semicolon in PHP.

This does not create a situation like the semicolon insertion in JavaScript,
however, and I don't perceive as an ambiguity or inconsistency issue.

Are you saying this detail about PHP causes problems of some sort? I can't
think of any. If JavaScript were to work like that, and only let you omit a
semicolon before a closing script tag, that would be absolutely fine with me.

------
ScottBurson
And so once again, Alan Perlis' famous quip is proved right: syntactic sugar
causes cancer of the semicolon.

Seriously -- look at the complexity of these rules, and then tell me that
Lisp's parentheses are worse.

~~~
ShardPhoenix
Javascript isn't exactly the typical case of semi-colon usage here.

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

[http://www.rockstarapps.com/joomla-1.5.8/products/jslint-
ecl...](http://www.rockstarapps.com/joomla-1.5.8/products/jslint-eclipse-
plugin.html)

------
mrchess
This blog post reminds me of individuals who will only drink high quality
naturally purified twice-filtered water from the mountains of Switzerland.

~~~
epochwolf
Which comes from Lake Michigan?

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

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

~~~
selectnull
Actually, that's not what Crockford is saying. From the same link: "Figure out
where the semicolons go. Put 'em in the right place. You'll be very much
better off." That is a quote from 13:02 into the video. There is a trancript
on the video, so you can read it too.

I won't claim Doug has never said something like that, but I doubt it. I
watched many of his videos that can be found and he is always evangelizing
learning the language, instead of blindly cargo culting.

~~~
jsight
Yes, I agree... what Crockford says makes sense to me. Know where they go, and
use them consistently.

This blog post doesn't make so much sense. It seems to say that you should be
aware of the rules at all times and strive to use as few semicolons as
possible (even going so far as to put them in front of statements). Yes, it
would work, but I don't really see this as more readable.

~~~
IsaacSchlueter
My recommendation to use minimal semicolons is a very weak suggestion. I took
great care to make that clear, and to point out a few cases where it makes
perfect sense to use more semicolons than strictly necessary.

My recommendation against lying is much more forceful.

------
axod
Use semicolons, always. Then you don't need to learn all the rules and caveats
and ambiguity.

~~~
reid
Actually, if you consider the return example in the blog, you do need to learn
some caveats and rules. That's the point.

~~~
axod
Anyone who would write return\n deserves all they get.

It's a fun example, but it would never happen in real life.

~~~
toolate

        function getCount()
        {
            return 
            {
                'count': 1
            };
        }
    

Not what I'd do, but a common style nonetheless.

~~~
IsaacSchlueter
It's also completely valid JavaScript that does something very different than
what it appears to.

    
    
        function getCount () {
          return undefined
          { // open code block
            'count': /*labelled line*/  1  //numeric expression
          } // close code block
        } // close function
    

LINE BREAKS CONSIDERED HARMFUL.

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

------
richtaur
Hopelessly pedantic … use them (or don't), but either way don't waste too much
time on this subject. Focus on things that matter more.

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

