I added an .editorconfig to every project at work. As lead it's my perogative to enforce standards. Personally I'm not super picky. If it's not mangled I have no opinion on formatting or editor choice of any dev on the team, except: tab inserts spaces, no auto-formatting an entire file allowed, and the editor must be editorconfig compatible.
Linters in CI enforce standards. I’ll admit it’s not as nice an experience as automatic formatting on every dev machine. But it’s how things have been done for a long time, including recently, in JavaScript, before prettier took off.
This is true only if the formatter is introduced mid-project. Additionally, for git, it only messes up git-blame, you can still traverse the history and see changes prior to an autoformatting change.
I’m mixed on this if you use tools like GitHub or gitlab where it’s fairly easy to navigate the history so my rule is picking a quiet time to autoformat (i.e. coordinating open branches) and then marking the commit clearly as having no other impact so people can avoid reviewing it line by line.
I hate to respond with just 'this' but this is the correct response.
The problems we've had are all because we can't get consensus to auto-format, but then someone gets frustrated because they can't understand the code they're reading after someone committed mortal indentation sins, so then they auto-format and bam, history is worthless again.
