BXG Blog

The False Economy of Go: Short Variable Names

I’ve been complaining about Go’s various time-saving misfeatures for a few weeks now. If you’re hungry for more, you can start with the first post in the series or find links to all of the posts at the bottom of today’s complaint.

Today’s episode isn’t really about the Go language so much as the Go style guide, specifically: What’s the deal with preferring super-short variable names? Get yourself a code completion plugin for your editor of choice and quit making everybody try to decipher what s or e refers to!

Single-letter variables are fine as a loop index or as an intermediate variable in couple of subsequent lines, but they’re totally inappropriate when spread throughout a larger function. Or even worse, an entire file. Let’s pick on a package at random: net/dnsclient.

As of revision 9a5bddd, there are 14 functions in this file. Of the 9 that take parameters, 7 have only single-letter parameters. Of the 9 that accept a receiver, 7 refer to that receiver by the letter s. Looking through the function bodies, only 2 of the 14 have any local variables longer than one letter. This file isn’t atypical for the Go code I’ve seen. Many of the functions are short enough to figure out with a minute of examination, but it would take even less time if the variable names helped the reader instead of obfuscating their purpose.

The Go language itself doesn’t force you use variables like this, but the style is recommended by the code review comments and pervasive throughout the community. Ugh.