Variable naming conventions

There is an ongoing debate regarding the ideal length for variables and type names in Go programs. On one hand, there are the proponents of the belief that all variables should have clear and self-descriptive names. This is a fairly common philosophy for people who have spent some time authoring code in the Java ecosystem. On the other side of the fence, we have the minimalists, that is, people who advocate for shorter identifier names, arguing that longer identifiers are too verbose.

The Go language authors certainly seem to be members of the latter camp. Case in point, here is the definition of two of the most popular Go interfaces: io.Reader and io.Writer:

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

The same short identifier pattern is widely used throughout the Go standard library code base. My take on this is that using shorter but still descriptive variable names is a good thing as long as other engineers that will be called to work on the code base in the future can easily understand their purpose within the scope that each variable is being used in.

The most common example of this approach is naming index variables for nested loops where, typically, a single-letter variable such as i, j, and so on is used. In the following code snippet, however, the index variables are used to access an element of the multi-dimensional slice s:

for i := 0; i < len(s); i++ {
    for j := 0; j < len(s[i]); j++ {
        value := s[i][j]
        // ...
    }
}

If someone who's not familiar with this part of the code is tasked with reviewing a pull request containing the preceding loop, they may find themselves struggling to figure out what s is and what each index level represents! Since the shortened variable names provide almost no information regarding their true purpose, to answer these questions, the reviewer would have to jump around the code base looking for clues: look up the type for s, then go to its definition, and so on and so forth. Now, contrast the preceding code block with the following one, which performs exactly the same function but uses slightly longer variable names. In my opinion, the second approach has higher information content while at the same time avoids being too verbose:

for dateIdx := 0; dateIdx < len(tickers); dateIdx++ {
    for stockIdx := 0; stockIdx < len(tickers[dateIdx]); stockIdx++ {
        value := tickers[dateIdx][stockIdx]
        // ...
    }
}

At the end of the day, each engineer has their own preferred variable naming approach and philosophy. When deciding on which approach to adopt, try to take a few minutes to consider how your variable naming choices affect other engineers that collaborate with you on shared code bases.