Silbinary Wolf
Golang Yarns: Unused variables is an error
Hey there friend! In this post, I’m going to tell you about my experiences with unused variables giving a compile error in Golang, from my first impressions to lessons learnt after months of using the language on a hobby project.
Frustration
When I first hit a “declared and not used” error message, my initial reaction was “What flag can I use to turn this dumb ‘feature’ off?”
After hitting this error message a few times and feeling the frustration of this “unnecessary error”, I jumped onto Google to try and understand the reasoning behind this design choice. I discovered at least one reason for this was to stop unnecessary importing of packages, which could lead to unnecessary bloat in your binary size.
When I read this, I felt partially satisifed but… I still felt annoyed by it. It just didn’t seem that helpful, especially when you consider that I was simply doing hobby work, I didn’t need this particular benefit.
Satisfication
After months of programming in Go for about 20-30 minutes a day on my commute to work, I found with experience that this feature also offers at least two more subtle benefits.
The first is that if you shadow a variable but forget to use it in the shadowed scope, you will get an unused variable error. If you’re like me and you have trouble visualizing pseudo-code from plain English text, here’s a code sample for clarity:
package main
func main() {
myVariable := "value"
if myVariable != "" {
// compile error! "myVariable" isn't used!
myVariable := "shadow"
}
myVariable = "not value!"
}
This hidden benefit probably saved me 10-20 minutes of debugging and it came from two seemingly unrelated systems complementing each other.
The second benefit you get is that your code becomes easier to read, both to yourself, others and also you in ~3 months. If your code was recently compiled sucessfully, you now have the guarantee that there are no unused variables in your program. I really love this reduction in noise and I get a warm fuzzy feeling knowing that the compiler isn’t doing redundant work.
The Disciplined vs The Nanny State
So I’ve talked about all the benefits of this feature, but what are the tradeoffs? What are we losing with this feature?
Well… we are potentially losing effeciency if our workflow is to make a big mess and then cleanup our code before committing. I think any kind of writer can attest to the idea that editing as you go isn’t the most effiecient way to pump out a book. It’s a lot easier to tidy things up and improve concision when you’re working with a more complete piece.
A veteran game programmer will find this feature infuriating. After all, this could simply be a warning or be ignored for “dev” builds.
In theory this is a good idea and incredibly easy to implement. However in my experience working in web development, developers tend to do the bare minimum, will ignore warnings and if the codebase got to a point where fixing errors that only happened in “production” mode was too much effort, the developer would most likely just ship “dev” builds because it’s easier on them.
Conclusion
University says, Don’t call your conclusion “Conclusion”, but I say, nah, she’ll be right.
So what’s the conclusion here? I guess… in conclusion it’s that we should keep in mind that if something seems like a bad idea on the surface but a group of people with decades of programming experience says its a good idea, then perhaps the value won’t become apparent until you also gain some experience.
