Add sigfmt formatter

[AlekSi]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.
• I agree to follow this project's Code of Conduct

How did you install golangci-lint?

Other

Your feature request related to a problem? Please describe

I would like golangci-lint to have a formatter for function signatures. I found two that look okay:

• https://github.com/feedr-aps/sigfmt
• https://github.com/SaintMaximov/gosigfmt

I tried the first one, and it works. Having it integrated into golangci-lint would be great.

That issue is unrelated to another project with the same name from #6242.

Describe the solution you'd like

See above.

Describe alternatives you've considered

Running github.com/feedr-aps/sigfmt manually.

Additional context

No response

Supporter

• I am a sponsor/backer of this project.

[bombsimon]

Thanks for the proposal. There is a new linter proposals template for discussions which is a better way to discuss new linters since the template contains a bunch of questions helping us. Also it's a good place to keep linter integration requests since they'll end up in the New Linter Proposals section that gives a good overview.

[AlekSi]

Should it also be used for formatters, though? The description does not mention that.

[AlekSi]

The template also seems to assume that I want to propose my linter with items like "I understand that tags must never be deleted or recreated once published", but that's not the case.

[bombsimon]

I think the template is fine for formatters as well, they're integrated very similar in golangci-lint.

In general only authors or maintainers of linters should add them to golangci-lint. For me it's a mix between a direct contact (and understanding it's added) from someone who can address issues and maintain it, but also out of respect so we know the author of said linter actually want's to include it in golangci-lint. Some related comments in #6522 (comment)

[ldez]

I moved the issue into the discussion: formatters or linters are evaluating in the same way.

FYI, I'm trying to avoid integrating linters/formatters without the certain form of consent of the author.

---

That said, IMHO, formatting a function signature based on the number of characters is not so relevant.
I could maybe understand something based on the number of parameters, but the number of characters is a bad metric.

Based on how the AST work (the AST is not really aware of lengths), this will be weak. I know that because this is a major limitation inside golines.

Also, formatting a signature can be more subtle than only putting parameters on separate lines: you may want to group then.

Having too long names for parameters is more a sign of bad function (and/or parameters) naming than a formatting problems.

Having too many parameters is generally a sign of several possible problems:

• the function/methods is doing too many thing (bad separation of concerns)
• the parameters must be grouped into a structure

I don't think that formatting the signature will fix those problems.

[bombsimon]

I didn't read the code (yet) so I don't know how line length is calculated and the issue implications of the AST but it seems a fixed width regarding number of columns is used and working here.

At my workplace we currently do arbitrary wrapping and I think it's a bit annoying because it's inconsistent. Different people decide to wrap function args arbitrarily so for us (or maybe me as "that" guy) it would be nice to have this rule and just have the formatter decide.

I agree it might be symptoms of different issues but the code grows fast and we've ended up with a lot of places where we more or less have to wrap them over multiple lines. At this point it's just too much work to refactor so I can personally see a need for a formatter like this.

I also don't think it's that uncommon, ruff, rustfmt and prettier all do this by default but they also have general built-in max line length rules so probably not a great comparison.

[ldez]

but it seems a fixed width regarding number of columns is used and working here.

Using column doesn't work:

func foo(
a string, b string, c string, d string
)

func foo(
a string, b string, 
c string, d string,
)

[ldez]

FYI, this is topic I already think a lot with golines, and there is no trivial and consistent way to handle that based on length.