Making every added formatting rule Optional about gofumpt

[mvdan]

I'm sorry but no - gofmt works across teams and projects because it's not configurable. gofumpt follows the same principle.

If there is a particular rule that's buggy or that's too controversial, it should be changed or removed. Otherwise there are no plans to add any configuration options.

[dnovikoff]

I agree that no rules of the gofmt shoud be optional, cause gofmt is a standart tool, provided by the developers of the golang.
Still the gofumpt is not a part of the golang and there is a reason why the added rules are still not a part of the gofmt. I think the reason is not the developers are "too lazy" to add them. Probably some formatting rules should not be forced.

Personaly I have come concerns about the following rules, which are quite sane, but could reduce redability in specific cases:
"Composite literals should use newlines consistently"
"Short case clauses should take a single line"

"Octal integer literals should use the 0o prefix on modules using Go 1.13 and later"
Even the go library code still uses the "0" prefix - not "0o" in their code.
Example: https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/os/tempfile.go;l=94
The spec says nothing about "0o" is preferred over "0" prefix https://go.dev/ref/spec
Most developers are used to the form of 0644, 0755, 0777 and the "0o644" looks wired and confusing to me. Still I understand that some developers may be used to the form of "0o". I agree that the form of octal prefix could be the same across project, still this form should be an option.

Anyway thanks for the answer about your plan for the library.

[mvdan]

The 0o prefix is more consistent with other prefixes like 0b. There's nothing wrong with the old format, and the spec of course doesn't say which one is "better", but the entire point of gofumpt is to enforce some amount of consistency. Sometimes the formatting choices may seem arbitrary, but ultimately it's all about this consistency between developers.