[1] https://rust-lang.github.io/rustfmt/?version=master&search=
I've had to make use of `rustfmt::skip` in various places to keep it from doing things like mangling the groupings and explanatory comments in `const` arrays or making code gratuitously tall and thin.
...and that sometimes means either `git gui` cherry-picking and only running rustfmt infrequently or applying `rustfmt::skip` too broadly because of errors like "error[E0658]: attributes on expressions are experimental"
(I'm in the process of migrating from cherry-picking to over-broad `rustfmt::skip` so I can use format-on-save.)
And that ignores the synergistic benefits of erasing all style-based co-ordination problems & arguments & bikeshedding & whatever else from the entire codebase. IMO it's a no-brainer.
Exactly this. I sat across from the poor soul who was assigned to creating the coding standards for our C# stuff. It tooks months. Nobody was happy, everyone had their own way of doing things: var vs. no-var vs. obvious-type-var, CONST_VALUE vs ConstValue. The work has been completed (the person in question quit soon after), people are still unhappy, there are still (and will always be) open questions. People nit coding standards in code reviews instead of looking for real issues. What a shitshow. If you remove autonomy concerning coding standards from the get-go, people never form these opinions.
If code is not optimally pretty, that sucks. Establishing coding standards is an bottomless pit of despair. Almost any opinionated formatter is worlds better than the worthless sisyphian task of establishing your own coding standards.
I just don't think it's a big win, but I've found it's a hard rhetorical battle to fight. Everyone's more cynically fearful of ugly code rather than having that extra leeway to write extremely readable code. I've definitely found this can throw the baby out with the bath water.
When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines.
The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.
The argument to match clauses/scoping for example is weird in a world where a formatter automatically applies indentation. It might make sense when you have to manually check them on print-outs without an Editor. I'd argue GNU style fulfills that role even better or Horstmann if you care about vertical real estate (or be daring and combine the two). And now everyone hates me.
In a way that I tell the requester "you better have some really, really good reason for wasting my time on this".
Hell, I've even had a new hire prepare an entire presentation to convince us to change the line-length to something different than "The Language Standard".
"We follow the language standard" and if you don't like it, convince upstream (This was Rubocop/Ruby) is another one I've used in the past.
Naturally both people just gave up. There really is a better way to spend time than on tuning and tweaking a linter. Nearly all linters have some way to document and define very local exceptions for that case when some external__dependency_IsMxing_camel_case or whatever.
As someone observed above it's the only win you are likely to get, as ugly often boils down to "something I have seen before".
There a few idioms that are actively helpful or harmful. For example, python making whitespace significant neatly meshes with human visual system. We are really good a picking up changes in indentation, not so good at lining up curly brackets. But best of luck trying to get 1/2 the population to accept that, even though it's objectively accurate.
On the other side, allowing too many levels of operator precedence seems to be harmful. I loved the conciseness when I was young. It was only later I noticed people struggled with some of my code because of it. Pascal (I think?) solved the problem by making combining some operators without parenthesis a syntax error. But since I only used Pascal when I was young, I hated it whenever I did use it.
So yeah, consistency is the only easy win. And as you say it's a big one: consistently formatted code is much easier to read than a miss-mash.
Rust's formatter not making up artificial alignment columns is the best thing about it.
Even though it's a bit ugly, this is a big win.
As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical estate and I've become used to that (even though it is inconsistent at times).
Any formatting rule is going to fall over eventually. Rust-fmt seems to make sane choices the majority of the time.