Member-only story
Naming Conventions in Go: Short but Descriptive
The written and unwritten rules
“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.
But while conventions are meant to make life easier, they may get overvalued and misused. It is very crucial to set in place conventions and rules for naming, but following them blindly can be harmful.
In this article, I will go through some of the important variable naming conventions in Go (the written and unwritten rules) and how they can be abused — especially in the case of short variable naming. Package and file naming, as well as project structure, are not in the scope of this article, as they are worth a separate article.
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
}
If you try to call doMagic from the outside, you will get a compile-time error.
Interface names
“By convention, one-method interfaces are named by the method name plus…
