From * To Javascript

Educators must contend with students’ prior knowledge of a subject. Sometimes the prior knowledge is advantageous—but not always. What we “know” may be wrong or incomplete. The same is true with programming languages. When learning a new language, you must contend with the baggage you bring from other languages you know.

Suppose you are C or Java programmer and you see this bit of Javascript code:

Probably you expect to see a boolean. In this case, true. But you are wrong. The output is undefined.

Your C or Java knowledge has conditioned you to mostly ignore whitespace and mentally parse statements using semicolons. But Javascript automatically inserts semicolons for you when interpreting your code. In particular, Section 7.9 of the ECMA specification says this:

When a continue, break, return, or throw token is encountered and a LineTerminator is encountered before the next token, a semicolon is automatically inserted after the continue, break, return, or throw token.

Whoops. I long for the day when we no longer manually format our code with whitespace, but leave it to the editor to apply our styles to the token stream. I still want text, just not spaces, tabs, and linebreaks.

Yes, the specification says that the return without a token on the same line counts as a single statement, and a return without an expression yields undefined. I don’t normally wrap my lines, but my motivation for writing this was a situation in which I had four clauses in a complex logical expression that I wanted to comment. I broke them apart and ran into the error I describe above. I won’t do that again!