He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.
I do think there's value in manual formatting some code sections. For example, very large arrays, or alignment of semantic parts of a group of mathematical expressions. Ultimately, I think the only thing that matters is that the code is readable, consistent and you don't spend much time on how it looks.
That said, if you have team members who somehow can't or won't copy the surrounding code style, then automatic linting sounds necessary.
See it like this - in 10 years when here is no original dev working on this, will this project still have the same code style?
With a nice .editorconfig the probability is very high that it's mostly consistent.
I can guarantee you any manual rules will be long forgotten and the IDE style will reign supreme - only your old "manual" formatting will stick out like a sore thumb.
Everyone on the team need to agree to the linting rules before using linters. Else they will keep wirting their code according to their habits , and then they start to modify the rule that dosen't fit their bad habits when linters hints to fix the code.
> run the language's standard formatter
Even with very smart linters like `ruff` it cannot fix all of the linting errors. You have to hand fix many of them.
What linter do you use that can just run and forget?
