fix linter warnings and add GH lint workflow

[syhpoon]

No description provided.

[sesposito]

I've left some comments questioning a couple of linter default rules, but if they cannot be changed or it begins too many discussions around personal preferences, then I'm in favor of just sticking with the defaults 👍

[sesposito]

Personally I prefer the use of the short assignment operator syntax here (and in other places) as it explicitly conveys the semantic meaning of the default zero value, can the linter be configured to ignore these? WDYT?

[syhpoon]

I'd say that in this case the problem is that the initial assignment is not very useful since it gets completely overridden in the following switch statement. To your point, the same clarity can be achieved by introducing an enum type alias so that's it's clear it's not a plain integer value here but an enum. Would this solve your concern, Simon?

[zyro]

I'm also in favour of the extra readability. Even if the value is overridden shortly afterwards it's an indicator that this should be the "base" case. If there's another way to achieve that I'm open to that too.

[syhpoon]

So I was thinking of something like this:

type LeaderboardSort = int

const (
	LeaderboardSortOrderAscending LeaderboardSort = iota
	LeaderboardSortOrderDescending
)

...

var sort LeaderboardSort
	switch sortOrder {
...

this way it's clear that we're dealing with enum and not a generic int, plus, given that the switch below is exhaustive, we don't really need a base case. In short, imho there's no loss of readability with this approach, but, if the consensus is to keep it as it was, I'll be happy to throw some annotations instead 👍

[syhpoon]

Okay, I reverted the "base-case" implementation and added annotations to ignore these.

[sesposito]

I'm a bit on the fence on this rule, I understand the value it may bring in preventing unhandled errors, but otherwise, omitting the return value assignment is much cleaner when that's the intent, and having to explicity ignore this around defer statements seems cumbersome.

[syhpoon]

I guess it's more of a personal preference here, I'd personally always prefer to explicitly show that I willingly ignore the returned error and not just forgot to handle it. I agree about the defer though, I'll take a look if it's possible to configure the linter to avoid having to annotate those.

[syhpoon]

Added a rule to ignore the cleanup function. By default it actually ignores quite a lot of stdlib functions in defer so this was the only custom edge case.