Hacker News Reader

There's a lot of FUD around Automatic Semicolon Insertion for some reason. Basically, the parser inserts a semicolon anywhere where the program is otherwise unparseable but a semicolon would make it syntactically valid. Importantly, this will occur even if you are otherwise using semicolons, so simply saying that you need to manually put the semicolons in doesn't help the situation since the parser may add them for you in places you didn't expect anyway. Leaving them out forces you to know the rules, but you should have known them anyway since otherwise they will bite you at some point.

ESLint provides--and StandardJS uses--the `no-unexpected-multiline` rule, which will insist that you insert semicolons in places where the meaning would otherwise be unexpected. In practice, with `semi` set to never and `no-unexpected-multiline` enabled, I find that I have never had a problem with semicolons that was not caught by the linter. By contrast, when I was afraid of ASI (since "omitting semicolons actually has an effect", eek!) I would find that I'd occasionally have mysterious issues where arrays were interpreted as indexes and so on. (I switched to semicolonless-style at the same time as I started using a linter, so I can't compare the two independently.)

There's a lot of FUD around not using a seat belt. Basically, if you are careful to not crash your car, your seat belt should not be necessary. You can die even if using a seat belt.

My standard of car safety relies on that each time you crash your car, a red light will flash telling you that you have crashed your car. It is very effective detecting car crashes, therefore, very safe.

Hm. In the case where the ASI inserts a semicolon where you wouldn't have expected one, how do the semicolons you already added where you would expect them help? Using semicolons in JS to avoid problems is like making sure the seatbelt is securely fastened across the seat before you sit down: there's a satisfying click and the worrying light on the dash goes off, but it won't actually protect you in an accident.

> Omitting semicolons actually has an effect in JavaScript, and there are many examples of that. The Google JavaScript coding standard advises specifically against it for good reasons.

I just gave Standard a try for the first time, kinda surprised I'd never seen it til now. Anyway, it seems to also check for those semi-colon gotchas. If I try to use no-semicolons incorrectly, it catches my mistake. (I tried by putting the return value on the next line)

Hopefully one day you don't forget to run it and break production :)

Usually good standards can be assimilated and make you code in a safer way, even if not enforced by a tool.

You could argue that a script, version control hook or continuous integration script can take care of it, but those are lines of defense that can go away in certain circumstances and you are unnecessarily raising your odds for an incident.

Sometimes people add a block comment to disable linting, and if you were relying on your linter to provide the fix to allow your bad habit of not using semicolons, then you are on your own.

The solution to "forget to run it and break production" is to add the linter to your CI tests, or even as a precommit hook.

I touch on this in my other comment, but it's entirely possible to forget a semicolon and break things no matter which style you prefer. Both semi:always and semi:never+no-unexpected-multiline enforce good standards which can be assimilated; like spaces vs tabs, they're just different standards that people tend to develop very strong opinions about.

Another solution is to prevent ambiguity and just terminate your statements with a semicolon.

Except using semicolons everywhere does not protect you from automatic semicolon insertion. You still need to know the rules. https://feross.org/never-use-semicolons/

Personally, no semi colons is a deal breaker for me. It's like a period at the end of the sentence that means, "That's the entire statement".

So, it's neat in the config-less way, but I won't be using it. (there is a semicolon version by the way https://github.com/Flet/semistandard )

Still with semicolons, many core problems remain: it's too permissive, and it's designed that way to maximize adoption.

If StandardJS was a standard for dating, its only filter would be that your potential date is alive and is a mammal. Use that Standard and you will have a lot of potential dates! such a great standard.

It may not be perfect for everyone, but in that case, no need to rage. You can just use any of the 38472647893242 different linters out there.

What I like about StandardJS is that I don't need yet another config file just for a linter. lintrc, babelrc, webpack.config.js, karma.config.js, etc, etc. Having one less thing for people to need to understand is a nice feature in and of itself IMO.

And I actually tended to disagree with some of the StandardJS choices before adopting it. After working with it for a few weeks, I realize it makes absolutely no difference. I just have a linter that works with no config.

For me StandardJS is the same as having no linter at all, because it doesn't take action on the problems that can be actually harmful, like the ones I mentioned.

An excessively long function, statement or a complex function is a liability because it almost certainly cannot be tested or reasoned about. And all the negative consequences of not being able to test or verify code.

Cyclomatic complexity seems difficult to lint. I tried, briefly, and decided that linters were much better more for catching mechanical problems than stylistic ones. Where do you set the line? 10? What happens if you have a function that's got a complexity of 11? Do you have to split it? What if that makes the code harder to read?

Maybe this makes more sense in a codebase where there's a variety of contributors of differing skill levels. I'm interested to hear about how other people use measures of complexity and function size.

Sure, you can create a Sorites paradox out of this...

https://en.wikipedia.org/wiki/Sorites_paradox

Eventually you will have to commit to an arbitrary value, and stick to it.

But there are cases in which it's no longer subjective if cyclomatic complexity is bad. If you have a 500 lines of code function with 50 return points and cyclomatic complexity of 100 it is very clear there is no way you can maintain that or write a unit test for it without playing Russian roulette each time you check in a change and therefore you can objectively say that code is not safe and should not be allowed.