I wish I could slap anyone who gives a hoot about tabs vs spaces. Fortunately modern languages like go are removing the version control problem that not caring about style and using auto-formatting IDEs produces.

I'm working in a couple of projects where there's a bunch of linter-checker things that prevent any PR merges (another... imo somewhat over-used tool) and... I split my time between Java, PHP, various SQL engines and various JS frameworks (react, extjs, vue, etc) and I'm constantly battling different mental models with various IDEs always showing different colored squiggles and highlights telling me all the ways I'm "wrong" about the code I've just typed.

Can't use double quotes! Always to use double quotes! "Prefer string/template interpolation" in JS Always do string concatenation per another project's standards.

Lots of different frameworks, languages, projects and companies all force different types of ceremony on formatting. "Hey, just let the tooling tell you!" turns in to constant UI distractions telling you that you're 'wrong' degrades (my?) performance. And... the value of most of these formatting things is pretty low, long term. I know that's heresy to some folks, and everyone I talk to sort of agrees, then says "yeah, but I really think standard XYZ is a good thing", but... it's nearly all preference, just like tabs/spaces.

That sounds like bad tooling. Why not have every project use https://editorconfig.org/ and then have your IDE auto-format? It shouldn't be popping up and making you fix it, it should fix it for you.

So there are tools that autoformat as you type?

let longVariableName = "hello " + this.name;

magically becomes

const longVariableName = `hello ${this.name}`;

without visually flagging it, just autocorrects as I type?

And... I can just quickly swap settings for different clients? Because one has eslint block any PRs that don't have "prefer template" rules followed but another client doesn't like that style, and don't want that style in their code because it conflicts with existing style.

I don't think that counts as a formatting issue. Yes, if your clients have hard rules about different coding styles at that level then it's not a technology problem (nor is it likely solvable with technology). I assumed we were talking about formatting issues like tabs-vs-spaces, in which case yes every single project could be different but auto-fixed.

thx. sorry, i sounded a bit snarky before and wasn't meaning to be. it's just easier for people to focus on visual issues vs operational/functionality. and switching between multiple projects/clients/standards illustrates to me how relatively unimportant some of these things are (but of course just imo).

I would encourage you should check out editorconfig more closely. The whole idea is that each project has a file that defines the simple formatting rules for various file types in the project/directory tree and your editor will automatically follow them on a per-project basis. It's surprisingly well supported across editors.

> using auto-formatting IDEs produces.

I strongly suspect a lot of the remainder of the tabs vs spaces reminder is actually about how it either constrains editor / IDE choices OR requires and investment of time to deal with whichever choice someone else made.

"Why do you care, my IDE just handles this" is pretty close to saying "use my IDE," on top of "use my convention."

That's why people are asking to push this problem down to the language level the way Go has done. Go defines both the "correct" format of the code as well as a standard way for any/every editor to enforce it (gofmt etc). That eliminates the double-headed subjectivity of both "use my IDE" AND "use my convention" down to just "use the standard convention defined by the language". And people love it because finally we can stop arguing about the stupid color of paint for the bikeshed and just bloody build the damn thing.

The solution isn't to force style on programmers within the language. It's to fix the shitty diff tools that flag whitespace changes as significant.

when people care whether you have

    if(foo) {

or

    if (foo) { 

or

    if (foo) 
    {

you end up in pointless arguments. I don't care about this sort of formatting very much (I have my own default style developed over years), but I do care when other people care about it, often to the exclusion of other factors.

"but we need these tools so that we don't argue about how to format code". Well... you could... just not argue about it in the first place.

Disagree. There's value in consistency, even for the shallow matter of formatting. There's a reason so many large-scale software-development companies care about coding standards.

You're right that it's not a matter of there being one true style. I agree with Kevlin Henney though that there are certainly wrong ways to format code - https://youtu.be/ZsHMHukIlJY?t=1027

I think it's not at all pointless to have consistent code style throughout codebase. I agree, though, it's pointless to argue (thus losing time) about "correct" style. It should be enforced on project or company level, no discussions between developers there.

> You can be exposed to them, but without understanding them, and experiencing both good, bad, and really bad 'solutions' to them, and understand the impact (on the business, on the code, on security, on maintainability, etc)... you just can't really get all that in 2 years.

I don't think this is about becoming expert. This is about learning at least very basics in multiple areas so that you are not completely clueless and know issues exist. When you redefine requirements to "2 years active learning worth of knowledge", you moved goalpost quite far.

> I've been doing this for a bit over 25 years, professionally now, and... there's a lot I don't 'get' with current stuff. But I've seen and lived enough projects, in enough different situations, to have a good idea of impact of tech decisions, and to understand how to make tradeoff decisions.

This is being senior.