For better or for worse this is part of the "Standard Style": https://www.npmjs.com/package/standard

It always seemed like an odd choice to me that would make people less likely to adopt it.

Important emphasis on the quotation marks around the word standard. From the readme:

> But this isn't a real web standard!

> Of course it's not! The style laid out here is not affiliated with any official web standards groups, which is why this repo is called standard/standard and not ECMA/standard.

> The word "standard" has more meanings than just "web standard" :-)

I’m not a fan of the naming, but I could also be biased because I disagree with some of the formatting rules.

Unfortunately in the JS community you cannot say these things without being punished. If you do anything else than strict eslint with "airbnb settings", or default prettier settings, your head goes off! Don't ever say this to your JS team mate. It's a very rigid community if it comes to these futilities.

This is... puzzling. Where do you see these attitudes? Both ways are perfectly cromulent and it's fine for people to have opinions.

In my years of JS dev the main thing I've seen from the community is "pick a style and stick to it. Be consistent." And that's pretty typical and sage advice of all programming.

The reason to downvote parent is that it's bringing up a tired debate. We may as well discuss tabs vs. spaces while we're at it.

If I remember correctly it used to be the case that every JavaScript repo came with it's own eccentric style. I'm certainly guilty of that. Now -- when we have these style "standard" style guides -- we've sort of settled on 3 or 4 competing standards. None of them look particularly bad (or at least not worse then my personal style cerca 2012).

Don't get me wrong. We still engage in stupid bikeshedding about semi vs. no semi, tabs vs. spaces etc. but I feel overall we've embiggened our spirit when it comes to code style debates.

No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received.

First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter.

Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to.

Third, this does not affect your own code. You are free and encouraged to use whatever formatting convention works for your own teams. Just make sure it’s consistent and enforced.

Keeping consistent style is anything but a “silly rule” and it’s essentially no effort.

It is a real problem, I've seen heated discussions in a few companies, and it can take out a big part of the fun you have in your work.

We really need to write an editor plugin/solution for this. Your editor should show the code in your preferred style, but saving it in the team's agreed style. And then a local-style.js for your own settings, and a team-style.js for the team settings. local-style.js in the .gitignore. Should be possible though?

It'd be possible but it's a non-trivial amount of work: think about things like linting or debuggers where line numbers might vary substantially, sequencing things in tools around merges and code review, etc.

The option you can do right now is to use something like Prettier where everyone's experience is entirely consistent and you have no cognitive load switching styles or dealing with inconsistency. This is basically free and means that there's a whole slew of high-emotion discussions which you can stop having for the rest of your career, in favor of working on things which actually matter. The older I get, the more that looks like pure win.

You could absolutely make that. It sounds neat.