The main selling point of gofmt, for me, is not that it formats my code perfectly (I don’t care. I really really don’t care. I’ve worked with code bases that had half the functions completely squished onto line, from declaration to closing brace. I work with code bases that have multiple indentation levels in the same file. Nothing about formatting has ever prevented me from doing my job. I don’t get why people get so worked up over it).
It’s that it makes sure time and energy isn’t wasted discussing meaningless subjective differences in opinion about formatting. It’s the joy of knowing that if I’ve run gofmt, whoever reviews it can’t be lazy and just point out a few formatting mistakes; they have to come up with something meatier.
gofumpt might be made with the best possible intentions, it does re-open the can of worms that gofmt closed.
I’ve liked the formatting gofumpt has enforced, but this has been my experience too. It creates diffs when I’m working across projects because not all are using it and I feel like I’ve gone back in time on this issue.
Does anyone know if gofmt undoes changes done by gofumpt in some scenarios? If that’s the case, I think tools like gofumpt should consider making it a design goal to ensure that doesn’t happen.
This is addressed in the first sentence of the README.
Enforce a stricter format than gofmt, while being backwards compatible. That is, gofumpt is happy with a subset of the formats that gofmt is happy with.
but I was wondering about running the other way around, because this is the scenario that’s likely to happen if one developer uses gofumpt but the rest use standard gofmt on the same code:
% gofumpt -d file.go
... 40 diff lines
% gofumpt -w file.go
% gofmt -d file.go # should not produce a diff. is this guaranteed?
But, if I had read further, this is addressed soon after. :)
and running gofmt after gofumpt should produce no changes.
I like the idea of implementing a superset of stricter rules vs the built-in tooling, provided the built-in tooling doesn’t create a diff as a result. For exploring new rules it could be a good experiment. Derw’s formatter is very strict currently, and loses some of the context if something is styled a particularly weird way. When I’m looking into new formatting rules, I’ll probably do something similar to gofumpt.
The main selling point of
gofmt, for me, is not that it formats my code perfectly (I don’t care. I really really don’t care. I’ve worked with code bases that had half the functions completely squished onto line, from declaration to closing brace. I work with code bases that have multiple indentation levels in the same file. Nothing about formatting has ever prevented me from doing my job. I don’t get why people get so worked up over it).It’s that it makes sure time and energy isn’t wasted discussing meaningless subjective differences in opinion about formatting. It’s the joy of knowing that if I’ve run
gofmt, whoever reviews it can’t be lazy and just point out a few formatting mistakes; they have to come up with something meatier.gofumptmight be made with the best possible intentions, it does re-open the can of worms thatgofmtclosed.I’ve liked the formatting gofumpt has enforced, but this has been my experience too. It creates diffs when I’m working across projects because not all are using it and I feel like I’ve gone back in time on this issue.
Setting this key in your repo’s
.vscode/settings.jsonfile will get all the VS Code people using it.Does anyone know if gofmt undoes changes done by gofumpt in some scenarios? If that’s the case, I think tools like gofumpt should consider making it a design goal to ensure that doesn’t happen.
It doesn’t undo any changes as far as I understood. In the Frequently Asked Questions the first question answers this (emphasis via bold mine):
Our design is to build on top of
gofmt, and we’ll never add rules which disagree with its formatting. So we extendgofmtrather than compete with it.The tool is a modified copy of
gofmt, for the purpose of allowing its use as a drop-in replacement in editors and scripts.If it did undo any changes I would expect that to be made more clear.
This is addressed in the first sentence of the README.
Thank you. If I understand correctly, I think the quoted text is only about:
but I was wondering about running the other way around, because this is the scenario that’s likely to happen if one developer uses gofumpt but the rest use standard gofmt on the same code:
But, if I had read further, this is addressed soon after. :)
I like the idea of implementing a superset of stricter rules vs the built-in tooling, provided the built-in tooling doesn’t create a diff as a result. For exploring new rules it could be a good experiment. Derw’s formatter is very strict currently, and loses some of the context if something is styled a particularly weird way. When I’m looking into new formatting rules, I’ll probably do something similar to gofumpt.