There are good reasons for not having a standard code formatting style in a team. They might be ones you don't agree with, but saying there are no good reasons is IMO a bit disingenuous. With mature team members, it's perfectly possible to respect each other's style and if executed well, it can have advantages such as being able to very quickly identify who wrote something (who to pester about something), making readability decisions locally instead of globally and benefits like that.
Of course, that requires a team with emotional maturity, which is I get, not very common in the software industry.
Reading this and your other comments I have two very conflicting vibes that I:
1. Hard disagree on the idea of multiple styles in a single codebase and think being able to identify writers of code by style rather than version control sounds like madness incarnate.
2. Massively want to read a blog post or something from you about your ideas on code style. Sounds like you have some pretty valid and well thought out ideas justying a philosophy of code style I've never heard supported before (I think normally disparate code styles in a code base would get interpreted as a code smell rather than a positive)
If style didn't matter at all, we'd be writing assembly or bytecode. But we don't, because code is written for humans most importantly. Reducing the code down to basically the AST makes it lose important semantic meaning; which defeats the purpose of high-level languages.
Hi! I don't have a website or a blogpost or anything, to be honest. If you want to chat about it, I'm happy to - my Discord is on my profile, my email is prisznyak.zsombor@gmail.com , or if you want to communicate with some other platform, let me know.
I suppose you never encountered git conflicts caused by differences in the autoformatter settings.
Or a lot of changes without reason, making it more time consuming to find the real change in the commit diff log.
I don't mind differences in code style. There is a standart called editorconfig, which IDEs support, which makes code style rules IDE independent.
Actually if you have people with experience and professionals, they don't care about a specific code style rule, they don't care if they switch the code style from project to project, they just want a standart set of rules for the whole team so that there are no issues caused by different formatting styles.
Of course, that requires a team with emotional maturity, which is I get, not very common in the software industry.