I spoke about Go and Clean Code in a couple of meetups and at the last Gophercon Brasil in 2019 (slides here, in Portuguese) and I am now breaking the presentation in a series of posts, starting with this one, to explain what kind code is considered clean in Go. The motivation behind this is to share a little after years of writing Go code on what kind of practices are considered good / bad.
My very humble opinion is that a clean code is more than just a series of Design Patterns or SOLID principles. We often focus on these things and we forget about what’s like to write a code that is easy to understand for other programmers in that particular programming language. So I always start with the language styleguide.
I struggled a lot when I found out that Variable names in Go should be short rather than long. I cried a little with my teammates, saying that it was just plain stupid. I was struggling with the fact that always, ever since when I was a fifteen year old kid learning how to code, my teachers told me to write meaningful and descriptive variable names. Examples were always from a Java code and a very descriptive method name.
When you see Rob Pike’s notes on his programming style, he very well points that: “Length is not a virtue in a name; clarity of expression is.” (under the section Variable names).
It took me a while that meaningful and descriptive can be short. And sometimes, when you combine these things, you end up with a better code.
And we do this more often in other languages than we believe.
In this particular example, i is a perfectly good name for the index variables, while sum is actually short enough so it doesn’t need to become s.
When Go’s Code Review comments says that you should prefer c to lineCount, it means that this code…
…is not more readable than this code…
Why is that so?
In both cases, i and c are short-lived variables. Their scope is tiny, the code block that its used is tiny. You can see right where it ends. You don’t have to scroll down too much.
On a more general rule, your variables names should grow according to its scope. Don’t go all crazy and use c instead of lineCount for package variables.
And avoid big scopes - but this is a subject for our next post. See ya! :)
Cool reference links⌗