I ran into this in the pre-webpack era where it was somewhat common to just concatenate JS together in a gulp build step. We imported code from two NPM modules, and each one was wrapped in an IFEE, but the first one didn't terminate with a semicolon. Not fun to debug.
Can You Find the Bug in This Code?
41–50 of 64 posts
Re: Can You Find the Bug in This Code?
#42Earlier quoted context omitted.
>Just end lines with `;`. But that's not always the solution, you still need to know when ASI kicks in and when it doesn't. "just end lines with ;" isn't true in multi-line arrays, in multi-line objects, and a ton of other situations where a semi at the end of the line is a syntax error. And while i'm sure you know that and didn't actually mean "every" line, it just goes to show that you already have the knowledge of…
You're absolutely correct. Jey provided the better phrasing of my comment: Use `;` to end a statement. The point I'm making is more bias toward using `;`, even when not strictly "necessary". This brings JS's statement parsing in line with most other languages. And yes, absolutely use a linter.
Or you can do what a past coworker did. We settled on standard.js for our linting in a project, and they don't use semicolons. The coworker hated this, so he setup his editor to auto-format into his preferred style on load, then on save use the auto-format option in standard.js to save it as the format that we agreed on in the repo.
He only ever worked with his favorite layout, and we worked with ours!
I'm not a big fan of holy wars in programming, i'm fine with either even if I do prefer one style over the other, but at the end of the day I just hope that everyone involved understands that it's just a preference thing for the most part. Linters will catch the edge cases for both styles, and if you really can't adapt to using or not using semicolons in javascript, there are probably other issues at play.
Re: Can You Find the Bug in This Code?
#43My problem with semi-colons is that when you force semicolons in a tslint config, applying an autoformat on a malformed input (forgetting a closing curly brace, for instance) will introduce a bunch of erroneous semicolons throughout the file, giving you a ton of syntax errors to clean up. If you’re lucky you’ll be able to undo before you continue, but I sometimes don’t notice until I’ve done a bunch of other work
Re: Can You Find the Bug in This Code?
#44The bug is in the coder.
Re: Can You Find the Bug in This Code?
#45Earlier quoted context omitted.
Close to 100% of semi-colons are noise in any given project. That's why.
Samewithwhitespace.
Not true. I'd really like an example where semicolons make JS more readable, if that's your argument. If you're using something like Prettier (and you should be) your code is formatted identically whether or not you use semis.
Re: Can You Find the Bug in This Code?
#46Semicolons are usually optional in JS. The 'usually' part if why it's a good idea to enforce usage of them to avoid situations like this. You don't even need to do IEEs for this - running a function on an inline-declared array has a high probability of creeping the array up as an index on the previous expression.
> Has a high probability of...
No. It either does or it doesn't. The spec is not ambigous.
Learn how ASI works, or you will run into trouble no matter if you prefer semis or not.
Re: Can You Find the Bug in This Code?
#47The real bug is the failure to use semi-colons. I literally cannot comprehend the non-use of semi-colons in JS.
If so, the failure lies with the spec. (personally, I like ASI)
I feel the same way about ASI as I do about forgiving HTML parsers. They're built to handle mistakes made by your average weekend warrior Grandpa building a website about his grandkids and pets. ASI is built to handle an "oops", not an entire codebase. That's why there are these odd edge cases. The same is true with the English language. If one were to send me a text with "do ya think" I'd probably figure out that it was a question... but why avoid the actual punctuation that assures that I communicate the intention 100%?
The explanations that have been given to me typically fall in line with, "well, to new comers, it won't make sense why you don't add a semicolon after a function declaration or if statement. I consider that a teaching moment.
But, I'll admit, this debate has little merit. Folks whom are dead set against using them are rarely convinced until they get bitten hard by a 2 hour hunt for an obscure bug. And folks that use them will probably end up with RSI or Emacs Pinky™
Re: Can You Find the Bug in This Code?
#48An even more common use-case that fails without semicolons by T.J. Crowder (2015): http://blog.niftysnippets.org/2015/09/automatic-semicolon-in... There are a number of cases where not having semicolons has its downsides, I'm yet to see a single case of an upside.
> I'm yet to see a single case of an upside. It's a signal of coolness from inexperienced programmers. That's the value proposition offered by semicolon-free JS.
I disagree, I think people who really care about semicolons in JS are people who just don't write a lot of JS. I can honestly say in the last 5 years of only writing front-end I have never been bit by ASI.
Re: Can You Find the Bug in This Code?
#49I think what's more confusing than ASI are the mental gymnastics developers go through to justify typing semicolons daily, rather than installing a linter once, or reading the ASI spec.
Python and Ruby support semicolons for occasional statement termination; why is JavaScript any different? I can't help but think "semicolons by default" would be regarded as ritualistic if the practice was never popularized in the first place.
Re: Can You Find the Bug in This Code?
#50An even more common use-case that fails without semicolons by T.J. Crowder (2015): http://blog.niftysnippets.org/2015/09/automatic-semicolon-in... There are a number of cases where not having semicolons has its downsides, I'm yet to see a single case of an upside.
> I'm yet to see a single case of an upside. It's a signal of coolness from inexperienced programmers. That's the value proposition offered by semicolon-free JS.
The reason why I made the switch was that it really irked me when one line missed a semicolon.
No warning, no error and completely valid code. It really triggered my proverbial OCD. That one function out of ten where I made that typo.
So I stopped, and it was a major relief. Note that I didn't use a linter at that time.
I don't really mind semicolons in languages where they are enforced, but I also don't end statements in Python with semicolons.