Consider golangci-lint config

[eleksir]

Not just stub thing but real config with reasonable strictness.

.golangci.yml

Attached example is a bit strict (it generates tons of warnings) but it works well for some of my projects.
And it shows warns about missing godoc comments as noted in #206 as well.

[eleksir]

I'll take this issue if it is okay to implement.

[mdosch]

I am fine with this, if you want to do the work. :)
@mattn what do you think about applying these coding/doc styles?

[selfhoster1312]

Related: current master branch doesn't build:

./xmpp.go:1628:10: c.ReportSoftwareVersion undefined (type *Client has no field or method ReportSoftwareVersion)
./xmpp.go:1631:11: c.ReportSoftwareOS undefined (type *Client has no field or method ReportSoftwareOS)
./xmpp.go:1637:9: c.SoftwareName undefined (type *Client has no field or method SoftwareName)
./xmpp.go:1638:9: c.SoftwareVersion undefined (type *Client has no field or method SoftwareVersion)

@eleksir if you need help with the Github actions integration i'm happy to help

[eleksir]

@selfhoster1312 thanks, but first there's a little bit of work to be done.
Future work stats:

823 issues:
* bodyclose: 1
* errorlint: 1
* exhaustive: 2
* gocritic: 23
* godoclint: 106
* godot: 96
* gosec: 3
* govet: 13
* grouper: 138
* misspell: 1
* modernize: 5
* nlreturn: 60
* noctx: 5
* nonamedreturns: 26
* perfsprint: 9
* revive: 51
* staticcheck: 4
* unconvert: 4
* wsl_v5: 275

It looks like work should be done by chunks, so it will be more than one PR. And help will be appreciated with some cases. (I noted a couple of places here and there where I'm not sure) I'll put them here, when I place my hands on them.

[eleksir]

I am fine with this, if you want to do the work. :)
106 of them according to stats, but most of it - no godoc at all.

To some defense of this a only can add - these doc-strings will popup in VSCode/goland as description hints, and looks like it is good to fill them up with some hopefully helpful bits of info. And honestly it is first thing wanted to start this task.

Anyway, if there is some guidelines to format godocs, i'd like to see it to avoid double work.

[mdosch]

Anyway, if there is some guidelines to format godocs, i'd like to see it to avoid double work.

Not that I am aware of. @mattn as most of the docs are probably also written by you I think it might be of interest to hear your opinion?

[selfhoster1312]

@selfhoster1312 thanks, but first there's a little bit of work to be done.

I would propose an incremental approach as we did in matterbridge. We have two golangci-lint configs:

• .golangci.yaml when you run golangci-lint, which prevents adding new warnings/errors
• .golangci-incremental.yaml run only on CI here with stricter params applied to the entire history of the codebase

Feel free to copy from these files (MIT license but arguably copyright does not apply for such small snippets, and i give you permission to reuse this specific work under any license of your choice).

I have some experience with CI systems so if you feel like you need some help to setup Github Actions, even outside of golangci-lint (maybe for example to make sure go build works, or to publish dev branch docs somewhere before new version release) just let me know :)

[eleksir]

Oh, there is first question - there is linter named grouper. It checks that module-specific constants, variables and types being grouped in one block. Say

const (
	// Current version of this prog.
	Version = "1.0.0-dev"
)

type(
	// SomeType describes data prototype for jsonl message.
	SomeType ....

	// AnotherType describes sata prototype for config.
	AnotherType ....
)

var(
	// msg is message we exchange with someService.
	msg SomeType

	// cfg is our running config.
	cfg SomeType
)

And to avoid mess it is good idea to move such declarations to separate files, say consts.go, globals.go, types.go.

Will we follow this idea? Or we should not use this module and leave things as they is right now?

[mdosch]

For consts I have already started this, except some exceptions but we could also move those consts to really have all in one place.

I think it makes sense, to avoid having similar consts or types defined in different places.

[eleksir]

Okay. I'll try to reduce linter noise related to missing/excessive blank lines (ready for review in #219) and trailing comment dots (looks like it started as prettifying godocs but as consistency measure spreads to all go comment strings).