[Shacklz]

If there's a small team, individual freedom can be perfectly fine, as everybody knows everyone and it's easy to talk with each other in case there are discrepancies.

For larger projects however, not having tooling set up that enforces certain consistency is an absolute showstopper for me. I'll either introduce it or I'll quit; I simply do not want to waste my time with developers squabbling over arbitrary formatting-choices or irrelevant coding-style-details that can easily be enforced by some tooling.

Of course, developer-experience is paramount. Meaning, the tooling must be easy-to-use and generally not stand in the way. Otherwise it can indeed create a lot of friction which will annoy everybody. But once this has been set up (properly!), it will make a lot of silly discussions and choices obsolete.

[josephg]

I hear you. But I’ve been programming for 30 years and I have some strong intuitions around where my code needs an empty line to space things out. Stuff like that. The day I first tried gofmt and it removed some of my carefully considered whitespace, I turned around, put blood on my hands in the old way and made a promise to the night that my soul belongs to me and gofmt will never sully my code with its corporate BS aesthetic.

Some consistency in a codebase is good. Naming consistency. Indentation. But people go too way far with it. Who cares if your JavaScript makes consistent use of semicolons? It doesn’t matter. It just doesn’t matter.

[neon_electro]

This is why linters are configurable; if your team doesn't care about consistent use of semicolons, ignore that linter.

Right?

[josephg]

Sure; but when I join a team and they've already got a linter set up with stupid pedantic rules, they never seem to appreciate my complaints about it. "Oh god, can we not have that conversation again!". I understand. But nobody is happy.

Carpentry isn't my jam, but I've taken up piano. I love it.

[Izkata]

I have similar feelings as GP about Black (probably the most popular python code formatter), which goes by the philosophy that linters should not be configurable because that just moves conversations about styles from the code to which rules to use.

[int_19h]

Black also behaves decently wrt empty lines. It does have some opinions on that, like two lines between functions and in some other contexts, and at most one line elsewhere. But inside function bodies, it will collapse multiple consequent blank lines into a single one, but it will never remove them altogether, so it's still possible to use them to logically structure code.