Letting Yourself Go Again

Continuing the Letting Yourself Go series, part 2 examines variable naming in Go. This is another area that feels ‘wrong’ to experienced OOP developers. If you’re transitioning to Go from PHP, Java, or C# and are skilled at writing maintainable code in those languages, idiomatic Go might seem different from what you’re used to. It isn’t that the code is of any lower quality than OO languages, but it may look it at first. Let’s take a look at variable naming conventions in OO languages like PHP, and compare this with the way the Go community names things.

Variable Naming in OOP

In object-oriented languages, variable names are typically expressive. More old-fashioned code, or perhaps code written by a less experienced developer, might have frequent single-letter variable names or custom abbreviations. The cardinal sin is doing this:

$num = 3; // Number of products in shopping basket

Why do we consider this bad? For the following oft-quoted reason:

“A comment is an apology for not choosing a more clear name”

“Uncle” Bob Martin

You can’t just put a comment next to the declaration of a variable, and expect people to scroll around looking for your note telling them what you would have called it if you weren’t trying to waste their time, right?

The Way Go Looks to OOP Devs

It’s understandable how Go code looks to a newcomer, approaching from the land of polysyllabic classes and their mouthful methods. C was invented for using on monitors the size of a shoebox with fewer pixels than your watch. Lines of code needed to be short. Important developments like expressive variable names, Red Bull and story point estimation hadn’t been invented yet, so they had to somehow code without them. If there’s one thing we can learn from how often Go devs tell us that their language has a garbage collector, it’s that it is supposed to be an improvement on C, not on Java. They are just giving variables tiny names to be retro, right?

Perhaps not.

Variable Naming in Go

The lengths of variable names in Go communicate scope. A one letter name means the variable’s scope is extremely limited, such as a for loop counter. About three letters implies its scope is a whole function. Global variables or variables whose scope is an entire package get one or more words in camel case.

It’s important to note that this can be done perfectly without comments everywhere explaining what variables are for. It can also be done perfectly without a whole lot of scrolling upwards trying to find out what a variable is. The shorter the name, the closer it is to its point of creation.

Additionally, typehints can be more expressive in Go than in most other languages. Consider the following:

type price float64

// ...

func foo(p price) {
  // ...
}

The type declaration is expressive enough here. If the function is short enough to fit on your screen, you will never lose sight of what the p stands for. The code is concise, without making you work to understand it.

The Law in the Letter

For more information, refer to the Google Style Guide.

“The general rule of thumb is that the length of a name should be proportional to the size of its scope and inversely proportional to the number of times that it is used within that scope. A variable created at file scope may require multiple words, whereas a variable scoped to a single inner block may be a single word or even just a character or two, to keep the code clear and avoid extraneous information.”

Google’s “Go Style Decisions”

Summary

Variable naming differences are one of the first things to jump off the page when we take a look at an unfamiliar language. The conventions adopted in Go may seem strange to those approaching Go from the direction of an object oriented language. However, there is no reason to think that the Go approach is really any worse or less readable than the conventions of other languages. Learning a new way of naming things is part of letting yourself Go.