This taboo of having opinions about code formatting shuts down legitimate criticism of rustfmt's design and implementation.
There are cases where rustfmt is just bad. I'd argue "objectively" bad:
• match arms are formatted individually, so nearly-identical arms can end up looking wildly differently if they hit different fuzzy logic thresholds. In Rust, enum variants aren't types, and macros can't see enum variants in the match context, so repetitive match arms are sometimes a necessary evil.
• deletion of a line can fold a multi-line construct into a single line. This makes diffs bigger and harder to review.
• rustfmt throws away any human influence on layout of code (short of sorting functions alphabetically). It doesn't merely change the boring bikeshedable mechanics like where the spaces go, but significantly rearranges how expressions are laid out and separated from each other.
For example:
let value = do().something().to().get().a_value_maybe()
.or_else(|| some_error_handling_here)?;
I think the code above is great, because the happy path is on one line, and error handling is on the other. Rustfmt
intentionally erases that:
let value =
do().something().to().get().a_value_maybe().or_else(|| some_error_handling_here)?;
That is IMHO bizarre. The value is what? Oh, there's spaghetti in the second line.
Gofmt is way better. It fixes formatting errors it understands, but when there are multiple correct ways to format a piece of code, it leaves the higher-level structure as-is. OTOH Rustfmt has an overriding opinion on everything. Non-negotiable heuristics replace all common sense.
There's no other production-quality formatter for Rust, so usage of rustfmt boils down to:
1. We must use something
2. Rustfmt is something
3. Therefore, we must use rustfmt