Naming Conventions in Go: Short but Descriptive

The written and unwritten rules

Dhia Abbassi
Apr 18 · 4 min read
Image for post
Image for post
Photo by chuttersnap on Unsplash.

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton

That’s not a funny joke. Writing is easy, but reading is painful. Do you ever find yourself wondering what a certain variable refers to or what the purpose of a certain package is? Well, that’s why we need rules and conventions.

The Written Rules in Go

Like any other programming language, Go has naming rules. Moreover, the naming has a semantic effect that decides on the visibility of identifiers outside a package.

MixedCaps

The convention in Go is to use MixedCaps or mixedCaps (simply camelCase) rather than underscores to write multi-word names. If an identifier needs to be visible outside the package, its first character should be uppercase. If you don’t have the intention to use it in another package, you can safely stick to mixedCaps.

package awesometype Awesomeness struct {

}
// Do is an exported method and is accessible in other packages
func (a Awesomeness) Do() string {
return a.doMagic("Awesome")
}
// doMagic is where magic happens and only visible inside awesome
func (a Awesomeness) doMagic(input string) string {
return input
}

Interface names

Getters

As mentioned in the official docs, Go doesn’t have automatic support for setters and getters, but it doesn’t ban it. It just has some rules for it:

owner := obj.Owner()
if owner != user {
obj.SetOwner(user)
}

The Unwritten Rules in Go

Some rules are not officially documented, but they are widespread within the community.

Shorter variable names

Go’s community promotes using shorter descriptive variables, but I think this specific convention is quite misused. Somehow, it’s common to forget about the descriptive part of it. A descriptive name will allow the reader to understand what it is about even before seeing it in action.

“Programs must be written for people to read, and only incidentally for machines to execute.” — Harold Abelson

  • Single-letter identifier: This is especially used for local variables with limited scope. We can all agree that we don’t need index or idx to understand it’s an incrementer. Using a single-letter identifier when it’s just limited to the loop scope is common and recommended.
for i := 0; i < len(pods); i++ {
//
}
...
for _, p := range pods {
//
}
pid // Bad (does it refer to podID or personID or productID?)
spec // good (refers to Specification)
addr // good (refers to Address)

Unique names

This is about acronyms such as API, HTTP, etc. or names like ID and DB. Conventionally, we keep these words in their original form:

  • productAPI instead of productApi

Line length

There is no fixed line length in Go, yet avoiding long lines is always recommended.

Conclusion

I tried to summarize the common naming rules in Go as well as when and to which extent we can apply them. I also explained the main idea behind shorter naming in Go, which is to find a balance between being concise and descriptive.

Better Programming

Advice for programmers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store