Simple tools to improve your Go code
Tools
Go has the chance to have many static checkers available, they help you to produce simpler and more reliable code. Nowadays, some editors directly integrate them but they are also stand-alone tools that you can run by yourself directly on your source code.
I’ll go through a list of the ones I find really helpful, please note that this list is not exhaustive.
gosimple
Starting easy, gosimple looks for things which can be simplified in the code. Let’s look through this example:
// validateContent returns whether or not this text/category
// is applicable.
func (s *Struct) validateContent() bool {
if strings.Count(w.text, " ") > 4 {
return false
}
return true
}
Let’s say this code is somewhere in my project, I can start gosimple on my project by running the command: gosimple ./... This will be the case for every tools presented in this article.
gosimple will indicate you that it is better to directly return the value of the boolean test:
should use 'return <expr>' instead of 'if <expr> { return <bool> }; return <bool>'
Obviously, this is an example but there is a lot of other rules managed by gosimple which can be found here.
golint
golint checks for style mistakes.
For example, it’ll report you when a public method doesn’t have any comment. If there is a comment, it reports if you don’t follow the best practice. If you wrote a method called newJsonData(), it’ll report you that it is a better practice to write newJSONData(), and so on.
go vet / staticcheck
Shipped with go, there is a tool that you can call using the command go vet.
This tool applies static checks to your code, meaning that some defined rules are tested, such as suspicious Printf. You know, the fmt.Sprintf("%s%d", var1) where you forget the second var in the parameters!
I would advice you to also use staticcheck, it is the same things but with other rules tested.
unused / unparam
When you use go fmt, the linter + your brain, you may think it’s enough to not let unused things here and there in the code.
unused is here to remind you that it is actually wrong and that it probably stays unused things: it reports when there is unused function or methods in your code, unused constants and so on.
While the detected parts are not harmful as they are unused, it is great to remove these extra informations, for example for newcomers on the codebase, it avoids having them trying to understand these things for nothing.
unparam is even more useful in my opinion as it indicates you unused parameters in a method or a function. An unused parameter in a function is probably due to the purpose of the function having changed (maybe it should be better to rename it?) or even a critical oversight as the go compiler doesn’t notify of unused method parameters.
errcheck
errcheck looks for errors returned by methods and not checked in your code. The compiler is not complaining when you silent an error, you do need someone to remind you that it is not necessarily a good idea! This is where errcheck enters the game.
gometalinter
It is a tool trying to regroup all the existing ones: it concurrently runs every tools and normalises their output. gometalinter avoids you the pain of running these tools one by one, but in exchange, you can be flooded by a whole lot of results.
The github repository is therefore a good place to start to have information on the major parts of existing static checkers for Go.
Conclusion
You probably can run them every times you save your files such as we do with go fmt, some great plugins such as vim-go or editors such as Visual Studio Code can directly integrate gometalinter, some plugins are even providing inline hints. For myself, I occasionally start them manually enjoying to improve my code and my best practices, step by step.
Finally, if you’re brave enough and patient, you can directly integrate them in your CI, before the build step.
This is up to you to decide when you want to apply these tools and that’s the great part.
Links
For more information on all these tools, I’ll redirect you to the gometalinter repository or to this github repository which also contains some useful information.
If you’ve find useful or erroneous information, please don’t hesitate to send me a tweet on @remeh, I’ll be glad to answer or to communicate with you.