Semicolons in JS is how you differentiate between someone who understands that code ambiguity leads to pain, vs someone who shouldn't be allowed near multi-line statements.
Honest question: how often does the code ambiguity due to lack of semicolons lead to non-obvious bugs?
I'm nowhere close to being a JS expert, but I've done some JavaScript-heavy pet projects and I've got an ambiguous statement interpreted wrong exactly once, and the cause was pretty obvious within a minute of looking at the error.
Good linters correctly highlight all missing semicolons as a symptom of sloppy, negligent, careless programming (or pointless syntactic showboating). It's also technically syntactically valid to omit braces around single statements after if, else, for, and while statements, but idiotic and dangerous to do that, too.
Please give a concrete example of this pain that you have actually experienced. I understand that ASI (automatic semi-colon insertion) is in theory ambiguous because you are relying on the compiler, or in some cases many different compilers, to execute the statement correctly. In practice, for over a decade, I have never run into such an issue. I suspect it's due to engineers trying to get too cute with their implementations.
;;;;;;;;;;;; // protective wall of semicolons
;;var a = 10, b = 20;;
;;
;;function add(a,b)
;;{;;
;;return a + b;;;;;;;; // this function MUST work
;;};;
;;;;;;;;;;;; // protective wall of semicolons
;[]... is one of two rules you memorize when you omit semis. It's not even that common of a case, though your own example doesn't even make sense.
I don't really understand the drama, just like people who use semis in place you don't need them. In real code, you should be using a linter anyways. At which point semis or no semis becomes purely an aesthetic concern. Like whether you use single or double quotes.
I haven't used semicolons in over 8 years and never had an issue. And with tools like eslint and prettier, you have no excuse to be making such trivial mistakes, like adding superfluous semicolons like function(){};
I have other more important rules I need to memorize with those brain cells, that I don't need to voluntarily choose to give myself more problems that require me to memorize ridiculous rules and obscure special edge cases to look out for all the time, that inexplicably screw me if I happen to slip up and forget to apply them. I stopped playing "step on a crack, break your mother's back" years ago, when I was old enough to actually have somewhere I needed to be.
Note though, that this ambiguity doesn't really affect the whole "whether to use semicolons" debate either way. If anything, it's more likely to occur in code that does use semicolons than in code that doesn't.
Intuitively, as a someone who uses C style languages, this becomes:
if(foo) doX(); doY();
Can someone confirm which intuition is correct?
I ask because, to me: it not being intuitive is a problem--even if it is not classified as ambiguous.
It being only contextually intuitive, also seems somewhat problematic--but maybe excusable if it is assumed you know some similar language going into it and it behaves similarly to that other language.
No idea what GP was trying to say, but the C style intuition is correct. The bug in that code is due to omitted brackets, it has nothing to do with semicolons/ASI.
I think I see what you're saying, but the context here was asking for cases where omitting semicolons causes non-obvious bugs. I mean:
if(x)
return
"foo"
clearly there's a bug there, but adding in semicolons wouldn't change the code's behavior. So it doesn't affect the "is it bad to omit semicolons?" debate either way.
