rustfmt also provides many options to customize the style, but the style guide defines the defaults, and most projects use those defaults.
I’d be curious if the team thinks this gives a positive or negative experience to users.
One of the few unquestionably good experiences I’ve had working with a large Go project is that gofmt precludes all arguments about style. rustfmt has knobs for days, and I wonder how much turning they get.
The bigger difference between rustfmt and gofmt are not the knobs, but the fact that gofmt generally leaves new line placement to the programmer, while rustfmt completely disregards existing layout of code.
OTOH to me rustfmt’s “canonicalization” is a destructive force. There are many issues with it. One example: I strive to have semantically meaningful split of code into happy paths and error handling:
let result = try.to().do.something()
.or_else(report_failure).thx().bye?;
To me this gives clarity which code is part of the core algorithm doing the work, and which part is the necessary noise handling failures.
But with rustfmt this is pointlessly blended together in to a spaghetti with weirdo layout like this:
let result =
try.to().do.something().or_else(report_failure).thx().bye?;
or turned into a vertical sprawl without any logical grouping:
let result = try
.to()
.do
.something()
.or_else(report_failure)
.thx()
.bye?;
rustfmt doesn’t understand the code, only tokens. So it destroys human input in the name of primitive heuristics devoid of common sense.
I want to emphasise that rustfmt has a major design flaw, and it’s not merely “I don’t like tabs/spaces” nonsense. The bikeshed discussions about formatting have burned people so badly, that it has become a taboo to speak about code formatting at all, and we can’t even criticise formatting tools when they do a poor job.
As a user, I like that rustfmt has some knobs, it lets me adjust the coding style to use within my own project, so it’s internally consistent.
What matters to me, as a developer, is that the coding style within a project is consistent. I don’t care about different projects using different styles, as long as those are also internally consistent, and have a way to reformat to that style, it’s all good. I care little about having One True Style. I care about having a consistent style within a project. Rustfmt lets me have the consistent internal style, without forcing the exact same style on everyone.
It’s worth saying that Rust is targeting C and C++ programmers more than Go is, and at least in my experience it’s those programmers who have the most idiosyncratic and strongest opinions of what constitutes “good style.” “My way or the highway” may not work well with many of them.
tl;dr the rustfmt team doesn’t want to be blamed for style decisions
That strikes me as a really smart idea.
I’d be curious if the team thinks this gives a positive or negative experience to users.
One of the few unquestionably good experiences I’ve had working with a large Go project is that
gofmtprecludes all arguments about style. rustfmt has knobs for days, and I wonder how much turning they get.The bigger difference between rustfmt and gofmt are not the knobs, but the fact that gofmt generally leaves new line placement to the programmer, while rustfmt completely disregards existing layout of code.
That’s one of the most frustrating experiences writing go code for me. I’m used to automatic line wrapping.
OTOH to me rustfmt’s “canonicalization” is a destructive force. There are many issues with it. One example: I strive to have semantically meaningful split of code into happy paths and error handling:
To me this gives clarity which code is part of the core algorithm doing the work, and which part is the necessary noise handling failures.
But with rustfmt this is pointlessly blended together in to a spaghetti with weirdo layout like this:
or turned into a vertical sprawl without any logical grouping:
rustfmt doesn’t understand the code, only tokens. So it destroys human input in the name of primitive heuristics devoid of common sense.
I want to emphasise that rustfmt has a major design flaw, and it’s not merely “I don’t like tabs/spaces” nonsense. The bikeshed discussions about formatting have burned people so badly, that it has become a taboo to speak about code formatting at all, and we can’t even criticise formatting tools when they do a poor job.
As a user, I like that rustfmt has some knobs, it lets me adjust the coding style to use within my own project, so it’s internally consistent.
What matters to me, as a developer, is that the coding style within a project is consistent. I don’t care about different projects using different styles, as long as those are also internally consistent, and have a way to reformat to that style, it’s all good. I care little about having One True Style. I care about having a consistent style within a project. Rustfmt lets me have the consistent internal style, without forcing the exact same style on everyone.
It’s worth saying that Rust is targeting C and C++ programmers more than Go is, and at least in my experience it’s those programmers who have the most idiosyncratic and strongest opinions of what constitutes “good style.” “My way or the highway” may not work well with many of them.
Go was originally intended as an alternative to C & C++, fwiw.