Given how pointedly opinionated Go is about how codebases should look like (unused variables are a compiler error!?), I'm somewhat surprised that `if err != nil return err` isn't some kind of built in warning. I do think Go as a language encourages this bad behavior.
Go is not really opinionated about unused variables, it's opinionated about not having compiler warnings, only errors. Which was a mistake, given that external linting tools had to pick that up.
Go is absolutely opinionated about unused variables, and its opinion is "that's a compiler error." It's part of what makes Go special. You should try writing some sometime.
> "Unused vars are warnings" is not a possible opinion for go, period. It's also not a possible opinion for go tooling like 3rd party linters.
Right, but that doesn't mean that Go doesn't have an opinion about unused variables. Go's opinion is that they are compiler errors.
> my point is that it's not a design choice but a side effect of choosing "we don't have compiler warnings".
What makes you think that? I don't think "we don't have compiler warnings" was behind the choice to make unused variables a compiler error. It seems like a deliberate design decision on the part of the Go team.
> Some have asked for a compiler option to turn those checks off or at least reduce them to warnings. Such an option has not been added, though, because compiler options should not affect the semantics of the language and because the Go compiler does not report warnings, only errors that prevent compilation.
> There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (Conversely, if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.
So I comment out a line or move around some code and want to quickly run it, or run the tests, whatever. This results in a cascade of either removing more and more lines and imports, or not only renaming to _ but also changing := to =.
This is of course the usual golang gaslighting. "It was easier to implement" becomes a "deliberate design decision".
There are tons of things that linters warn about (today), that should have been errors too by their logic.
Real question: For other languages, like C and C++, that warn about unused variables, do you ignore these warnings? When would it be a good idea to allow unused variables?
There's plenty of stuff that I have checked by a lint test before commit but is allowed to stick around in the codebase for a while locally as I work.
e.g. if I have a debugging function that I'm adding/removing calls to a lot I'd like to be able to leave the import for it in place until I'm done even if my current step isn't using it.
