Hacker News Reader

Comment by chrismorgan | Hacker News Reader

On the indentation one:

  function createNewArray(item) {
    return
      [item]
  }

The author claims this produces “Uncaught SyntaxError: Invalid or unexpected token”. This is incorrect; you end up with the body being `return; [item];` thanks to Automatic Semicolon Insertion, which is unlikely to be what was intended, and will produce a warning in some environments (e.g. “unreachable code after return statement” in Firefox), but is not a syntax error.

I presume the author wrote slightly different code. Most especially, I don’t believe anything is ever indentation-sensitive.

View on HN

This is why I hate that Javascript has automatic semicolon insertion. A whole new set of rules to keep in mind because some developers can't be bothered to put semicolons behind their expressions and statements. Unlike languages like Python, which have been designed from the ground up to avoid semicolons, or Bash, which requires very explicit multi line splits, Javascript is just not a great language to work without them and the language clearly suffers for it.

Javascript shouldn't be indentation dependent, but I have no trouble believing that it's doing something weird to indents because of this "feature".

I'd just like to add that Go has automatic semicolon insertion, and I have never experienced any surprises with it, thanks to gofmt.

I never have trouble with automatic semicolon insertion in real JS-based projects thanks to similar format tools. JS only really has this problem when it is serving its unique position as the scripting language of the web.

Go doesn't have automatic semicolon insertion. It's just not required unless for splitting multiple commands on the same line. So falls into the same category as Bash in the GPs examples. Thus Go's syntax has been designed around having semicolons omitted.

Whereas JavaScript technically requires it but many browsers decided to support parsing missing semicolons for the sake of making bad websites render (much like how most browsers will support a variety of incorrectly formatted HTML documents as well). The problem here is that JavaScript's syntax wasn't designed to have semicolons omitted. Which leads to all sorts of edge case problems and no clear answer on how they should be handled.

The JS part of your comment isn't correct at all. ASI rules are fully described in the very first JS spec, and in 20+ years of JS coding I can't recall ever having heard of browsers handling it inconsistently.

Maybe it's the way the language is taught that has changed? Originally (pre-ECMA days) you were taught that you should always include a semi-colon. The older specifications certainly don't encourage dropping semicolons liberally either. Take this passage from the specification:

> Most ECMAScript statements and declarations must be terminated with a semicolon. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

Which, to me at least, reads as saying JavaScript must include a semicolon but interpreters must be tolerant of the occasional missing semicolon where intent is obvious.

Somewhere along the line the attitude seems to have changed from "you should include them" to "don't bother". Or at least that's perception I get these days.

I've not been heavily involved in JavaScript for a few years but I was one of the early adopters back in the days of Netscape Navigator and, later, Internet Explorer (albeit with it's differing but ever-so-similar "JSScript").

As an aside, since I'm talking about the early days of web scripting, wouldn't it be great if we brought back the language property of <script> to support other languages. Wouldn't be sensible in practice (for a whole plethora of reasons) but one can dream....

The second most popular formatter is semi-colon-less https://standardjs.com/ Also yes, strong agree the web should support other languages and it is very easy to achieve by integrating the polyglot and interoperable graalVM

> Originally (pre-ECMA days)..

JS appeared in Dec 95 and the first ECMA spec came in June 97, so that's a pretty narrow window. But it's certainly true that ASI style (omitting semicolons) was relatively rare before, say, 2010-2014 or so. Its subsequent rise in popularity is probably thanks to Node (which uses ASI style), and a small group of ASI developers whose code suddenly got more visible once npm came along.

But as a practical matter, the rules on ASI have been the same since forever, and the rules are that they're nearly always optional. The only realistic case where omitting them causes issues is when you start a line of code with a parenthesis or a square bracket. Back when ASI first got popular that was the one big gotcha, but nowadays thanks to linters even that's not an issue.

What you may be remembering is, some years back there were some cases where certain JS tools didn't support ASI. Famously, there was a thing where a popular minimizer (JSMin) broke ASI code and Crockford didn't want to fix it because he didn't like ASI style (he later relented). But I've never heard of an actual JS engine not supporting ASI correctly.

> JS appeared in Dec 95 and the first ECMA spec came in June 97, so that's a pretty narrow window.

In theory yes, in practice not really. IE4 was the first version of JScript to be based on ECMA and that was released at the end of 1997. But in that era people didn't update regularly. Sure some folk (myself included) installed IE4 on top of Windows 95 SE[1]. But a lot of people wouldn't have had access to IE4 until they bought a new PC with Windows 98 pre-installed. So there was a good few years in practice.

Also worth noting that the web changed so much between 95 and 98. It might have only been three years in real terms but it felt like a lifetime in terms of technical revolutions.

[1] If I recall correctly, I had IE4 because it came on a .Net Magazine cover CD (not to be confused with Microsoft .NET: https://en.wikipedia.org/wiki/Net_(magazine) )

What is this set of rules exactly? As far as I'm concerned all you have to do is not put newlines between your "return" and whatever is being returned, which is hardly a common thing anyways.

The rules are here: https://262.ecma-international.org/7.0/#sec-automatic-semico...

Generally, the rule seems to be "insert a semicolon wherever the syntax messes up but can be fixed by adding semicolons". Then there are some special cases (++/--/continue/break/return/throw/arrow functions/yield) with more specific rules about where semicolons are placed and when; those are probably why the example produces "unexpected" results.

I think the added complexity of these special rules and cases are an unnecessary burden, and honestly the language should never have allowed leaving out semicolons when it was clearly designed to have semicolons.

Those contrived cases do not happen in practice. What does happen systematically though is the clutter and cognitive noise of semicolons.

Semicolons are like the periods of sentences It's so much easier to read something someone else wrote when thoughts are properly terminated Why would you ever demand that semicolons are removed They also prevent issues such as pronouns like SemanticStrength if used with mechanical automatic period insertion

Seriously, semicolons are something that was baked into the design assumptions of JavaScript. Python's an example of a language where the syntax was clearly designed from the inception to avoid them. Most such languages make explicit tradeoffs and TBH I'd much rather have semicolons than whitespace sensitivity.

No the analogy is wrong. I appreciate your example devoid of periods and while I agree periods in natural language significantly reduce the cognitive overhead, it is only because sentences in english can have multiple statements.

Periods are not needed if each sentence span exactly one line, which is the case in programming languages. the separators &&, ||, () do the intra statement disambiguation while for interstatement {} suffice. ; bring no value in practice. Using multiples semi colons on a single line is pathological code that should never exist in the first place.

When I code in Kotlin (which is not whitespace sensitive like python) I really realize that reading semicolon less code is smoother, it takes less cognitive resources (parsing is faster) and is more pleasant because the reading is not interrupted by vacuous symbols. There are no ambiguities in practice. The thing is, habits take time to die but ask anyone that has experience in an officially semi-colon less programming language, most will tell you it is a net improvement. BTW the vast majority of newer programming languages are semi-colon-less (Kotlin, Go, Swift, Julia, Scala, etc)

Shell commands can be written as a list

A series of individual invocations of arcane commands; sometimes with pipes

Though it is not uncommon for one-liners to exist (sometimes with sub-shells). In that case the semicolons are not optional. Even in cases where another type of escape is used to visually break up the one liner into a list like series of commands which happen to be run concurrently; most frequently for really long pipe-sets.

Yes semi colons can be useful for shells and other DSLs

Putting each "sentence" of code on its own line is actually the crutch that leads to low density and high line counts. As humans en masse become more comfortable parsing and writing machine inter-languages I imagine things will trend the other way.

It is fine to do something like:

   return (
      [item]
   )

or for this case:

   return [
       item
   ]

You could do other things to prevent it from sticking out of the side of the monitor but if it is to say return true if this and that and that and that and that it would (to me) look better on separate lines.

Prettier can screw that situation up pretty badly. A stray return can suddenly turn into a multiline return statement with boolean logic and assignments inside.

One particularly annoying case comes up when using IIFEs:

    let c = a + b
    (() => { ... })()

This is evaluated as:

    let c = a + (b(() => {...}))()

which usually results in "TypeError: b is not a function." Obviously this can be solved with a semicolon after the "let c..." line, but another common approach is to just prefix all IIFEs with semicolons, since empty statements are no-ops in JS:

    let c = a + b
    ;(() => {...})()

I personally prefer to forego semi-colons, but I have a hard time getting worked up over it either way.

Reply on news.ycombinator.com