> Able to have the confidence that we're checking for every situation that could occur on an enum type across the codebase is one less thing I need to worry about.
If you can write the indulgence (permission to sin) into the code it becomes self-documenting and that seems reasonable
e.g. #![allow(dinosaur::nonsense)] in Rust tells the tools that you know you're not supposed to do whatever dinosaur::nonsense might be, but you want to do it anyway in the following code and the hypothetical dinosaur linter shouldn't bother you about that.
When a maintenance programmer is staring at this block of code later, the fact you explicitly intended to do dinosaur::nonsense is right there, documented where it happens, and they can decide if the proper course of action is to leave that as it is, fix the code to not be dinosaur::nonsense, allow raven::stupidity because the new Raven linter is better but now warns about the same problem under a different name or what.
Golint is the worst precisely because it isn’t configurable, and some of the things it looks for are idiotic. “should replace i += 1 with i++” is probably the worst advice I have ever received.
I can see Go's point here though. Unlike C-style languages where i++ is an expression, in Go it's only a statement, it has no value, which eliminates some footgun opportunities.
It's a halfway house to a language like Swift or Rust where none of the assignments have value. So, in a context where you don't want a value, arguably i++ is a better choice by eliminating a footgun. I don't hate it.
I'd rather just use go vet + staticcheck. Way simpler, no complex configuration, and no license concerns :)
and then you can create a file like the following and add whatever analyzer provides value for your specific case (including this exhaustive), easily. Example: https://github.com/FiloSottile/mkcert/blob/master/analysis.g...