gofumpt mutates const blocks and their doc comments about gofumpt HOT 5 CLOSED

Agreed that the rules should be simple.

I'll go ahead with leaving const and import groups alone, most likely pushing the commit tomorrow. I'll reopen this issue to remind myself.

Thanks again for the helpful feedback - it was useful to help me make a good decision!

from gofumpt.

Perhaps a simple way to stop annoying developers is to not simplify declaration groups (parentheses) if there is a comment attached to the whole group. I agree that the docs can be broken very easily in this case.

Would that make the rule less painful for you?

from gofumpt.

It would certainly make it less painful, as there'd be fewer cases where a block of mine got destroyed.

However, in a common case where I write a const (…) block but fail to preemptively add a doc comment, I'd still get the scope destroyed. Knowing my habits, I'd save (and therefore run gofumpt) before putting the doc comment. Then I'd need to add a doc comment (possibly only to disable the block destruction) and put the parentheses back in. I'd grumble about it the entire time, and that's with me knowing the "doc comments disable const (…) flattening" rule. If I didn't know about doc comments, I'd have to search Stack Overflow for an explanation, as gofmt doesn't do anything like that AFAIK.

Furthermore, if I were left with an iota at file scope (as in my example above) I'd be outright confused by what the intent of the code was. I'd be quadruply confused if I had two separate iotas at file scope, lifted there out of two separate const blocks.

from gofumpt.

Thanks for the extra information. The original issue was about the buggy comment behavior, so I've closed the issue as fixed for now.

Knowing my habits, I'd save (and therefore run gofumpt) before putting the doc comment.

I tend to run gofmt/gofumpt manually myself; perhaps this is why I don't see the pain as often.

The point about iotas is a good one. We could skip the rule if the declaration group contains an iota identifier, though.

Aside from the comment and iota points, I'd still like to keep the rule around; I don't think people should commit unnecessary declaration groups to branches. Do you have any more ideas to reduce the annoyance, aside from removing the rule entirely?

For example, perhaps the rule could be relaxed to only work on var declarations. Top level imports and consts tend to grow over time, but top-level vars don't tend to as much. And I think most of the real cases I've seen in the wild have involved vars, and not consts/imports. I'm not bothered by unnecessary groups in imports, actually, but I only included them for consistency.

from gofumpt.

Do you have any more ideas to reduce the annoyance, aside from removing the rule entirely?

Nothing comes to mind. Plus, having a long list of exceptions makes it hard for a user to understand when gofumpt will change the code he's working on. When a user can't predict what a tool will do, that makes it effectively nondeterministic to him. This unpredictability is its own source of annoyance.

Generally, when I see a one-item const block, I think "this too shall pass", figuring that more constants will be added later. The one-item const block won't be an eyesore for all that long, relative to the time the codebase will last.

from gofumpt.