go-critic

go-critic copied to clipboard

Name: mutexHat Before:

struct {
	...
	rateMu     sync.Mutex . // unclear which fields are protected
	rateLimits [categories]Rate
	mostRecent rateLimitCategory
}

After:

struct {
	...
	// rateMu protects rateLimits and mostRecent.
	rateMu     sync.Mutex
	rateLimits [categories]Rate
	mostRecent rateLimitCategory
}

Thanks to @dmitshur and his blogpost https://dmitri.shuralyov.com/idiomatic-go#mutex-hat

I like proposed checker name. :smile:

To clarify, in that entry, the idea was that the comment was implicit and therefore not required.

So, without needing to write the comment, the above is implicitly understood to be equivalent

In practice, context and situation will determine whether it's worth adding the comment. But I think there are many valid situations where it's not needed.

@dmitshur, best thing we can do is to find best bet candidates for field re-arrangement (or comment addition). Not sure this check can be false positive free or as smart as we might want it to be.

Still can be good enough for legacy projects audit.

Thank for comments, guys. Issue isn't written in a stone. So we're free to decide what do we want 😉

Ruleguard, probably? @quasilyte