Warnings vs Errors

Deciding where to draw the line between warnings and errors can be a challenge. Warnings typically log a message but allow the user to continue while errors must be fixed before the program can continue.

In the case of compilers, the downside of warnings is that they're easy to ignore. I've seen many large C++ and Java projects where the warnings have built up over time to the point where there are hundreds or thousands of them. It's a difficult hole to dig your project out of. And you end up missing important messages from the compiler. I've seen a bug investigation take several days only to find we missed a buried compiler warning from a recent change.

Go doesn't have warnings. This can be annoying for newcomers when they see an unused local variable error for the first time. Or if you want to comment out a section of code temporarily to see what happens and trigger the error because the prior variable declarations weren't commented out. Overall, it's probably a net win since it catches unintentional variable name swaps and typos.

However, there are plenty of Go linters built on top of the language. If you decide to use them, it's your call how the ouput is treated. But you'll probably have to lean more towards warnings since some of the checks have the chance of false positives. Alternatively, you can tweak the linter configuration to meet the needs of your project.

Since I brought up linter configuration, one pattern I'm not a big fan of is using code comments to control the linter and ignore specific warnings on specific lines. If they are used occasionally and the comment is concise, it can be useful for future readers. But once you start down this path, it's easy to get carried away and bloat the actual code with linter comments, making it harder to read.