It seems to have a formatter option in the `fix` argument you can give it.

The authors should probably be selling it on that point since it seems to be its strength, it doesn't have many rules along the lines of the static analysis that people look for in linters.

Some people (tech leads, CTOs) care a lot about formatting but I wouldn't make teammates go through a linter for that, it's a rather surface concern.

The reason that those people care about formatting is that it matters when the code is used to communicate with other people, not just with machines. Having a consistent style within the team, means the team can communicate more easily - even if the net effect for an individual working on a codebase alone is minimal.

Yes but realistically, save for the code that someone who's really inexperienced or sloppy would write, fixating over whether someone is writing

     select a, b, c
     from foo
     where bar = 'quux'

rather than

     SELECT
         a,
         b,
         c
     FROM
         foo
     WHERE
         bar = 'quux'

is petty and immaterial to what the code communicates.

Worse if it's about details within the roughly the same style.

Edit: but if there's a code formatter that can be seamlessly added to the development environment, it makes sense to use it. It's just that if there's no tool support, such things are of little contribution.

In trivial examples when we are all relaxed then yes, you would be right. It’s non-trivial occasions when we are stressed and trying to read someone elses code at two in the morning when I really value strict code style guidelines.

The ability to read complex code when we are in situations where we are not functioning at 100% is vastly under valued when one talks about developers capacity for comprehension.

Code isn't meant to be read by computers - it's meant to be read by humans (including yourself in three years when you've forgotten everything). Code sugaring and style adherence are vital portions of retaining a maintainable and flexible codebase.

Yeah I know the spirit. I'm saying it amounts to absolutely nothing in readability. If there's any formatting at all, it's structure and not particular whitespace and comma placement conventions that make or break readability, the rest is code quality theater.

It does actually matter quite a bit in readability in my experience - when you have a bunch of noobs, and a bunch of senior folks, and a bunch of interns, and a bunch of contractors all slinging code around for review to each other.

Many folks will get sloppy (in syntax and cleanliness) or misunderstand things - which requires the reviewer be able to clearly and quickly see what they are trying to do to catch that - especially as deadlines approach. The more it slips, the more slipping becomes the norm, and the messier and harder to understand everything gets - which makes later work harder as well.

If what you're showing is the standard, I guarantee 25% or more of the requested changes (which already won't meet whatever standard ANYONE sets strictly when first proposed) will be even worse. If that even worse becomes standard, etc, etc.

Part of their job is to set the 'reasonable' ideal, and attempt to enforce it. It won't happen universally, or even necessarily often, but it pushes things more towards maintainability and obviousness, which is opposite of the normal trend in any group of people. The larger the group, the more of a problem it is, and the harder they need to work to do it.