single-letter variable names

[Shawn Milochik]

I've noticed that a lot of Go code, including the tour, the standard library, and lots of the code users post on this list, use single-letter variable names almost exclusively. To me, this makes it much more difficult to understand the code. I don't come from a Java background and don't use an IDE -- I'm not looking for hundred-character names or anything. But what's wrong with using short words like count, num, index, etc.?

It can't be more efficient for the compiler, and the mantra is that code is read much more often than it's written anyway. I don't think it's a preference, like tabs vs spaces, where to put the curly braces, or vi vs emacs. If you're reading code, the more expressive variable names are the easier it is to comprehend. I understand single-letter variables for things like the index in a for loop or array index. But it seems to me everything else should have meaning.

Am I just missing something? Why is this the standard? So far I'm loving Go and have started reading the standard library to try to learn it better. All the single-letter variable names make it take a lot longer to read and understand a 5-10 line function that I feel like it should.

[David Symonds]

On 14 March 2014 12:19, Shawn Milochik <sh...@milochik.com> wrote:

> I've noticed that a lot of Go code, including the tour, the standard
> library, and lots of the code users post on this list, use single-letter
> variable names almost exclusively.

I don't think that's true. It's certainly common to use single letter
names for very common concepts, such as i for a loop index, but it's a
long way from "almost exclusively". There's plenty of "dir", "path",
"name", "addr" and other similar short-but-not-single-letter names in
use in the standard library. Perhaps you happened to get unlucky and
only looked at some Go code that isn't representative?

[Caleb Spare]

The section titled "Variable names" in this article

http://doc.cat-v.org/bell_labs/pikestyle

documents some of the background ideas. The details differ slightly
but I think it's representative of the philosophy behind some of the
naming.

-Caleb

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Bushnell, BSG]

My favorite line in those wonderful gems is this:

"I eschew embedded capital letters in names; to my prose-oriented eyes, they are too awkward to read comfortably.  They jangle like bad typography."

[Dan Kortschak]

On Thu, 2014-03-13 at 18:35 -0700, Thomas Bushnell, BSG wrote:
> My favorite line in those wonderful gems is this:
>
> "I eschew embedded capital letters in names; to my prose-oriented
> eyes, they are too awkward to read comfortably. They jangle like bad
> typography."
>

Habituation is an amazing thing.

[Shawn Milochik]

On Thu, Mar 13, 2014 at 9:23 PM, David Symonds <dsym...@golang.org> wrote:

I don't think that's true. It's certainly common to use single letter

names for very common concepts, such as i for a loop index, but it's a
long way from "almost exclusively". There's plenty of "dir", "path",
"name", "addr" and other similar short-but-not-single-letter names in
use in the standard library. Perhaps you happened to get unlucky and
only looked at some Go code that isn't representative?

It's entirely possible. The majority of the variables in the tour are single-letter, and I started off reading the fmt library (since it's the most-used in the tour), which has an awful lot of single-letter variables.

Maybe I should get past the hump with Go before I start making generalizations. I also have the same impression from C code I've seen, and it seems like it's extremely common to use single-letter variables there as well, and Go is related to C. It's telling that the notes linked above are for C, although I understand the Pike connection between C and Go.

The pattern I see is highly valuing terse code. I think that's good when it makes a function more elegant, and bad when it makes "nodePointer" into "np" due to readability, to glean an example from the page above. When code is read more than it is written, especially by more people than just the author, I just think it makes it a lot harder than it has to be.

Maybe making it harder to read makes you have to pay more attention and you're less likely to miss something, but I don't think so.

[Andrew Gerrand]

From golang.org/s/comments:

Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex.

The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names.

Andrew

[Shawn Milochik]

Thanks to everyone for the replies. This is a very helpful, mature community. I definitely have a way to go to become fluent with Go's culture and idioms, but I am looking forward to it. The language is great and the people seem thoughtful and intelligent.

[Thomas Bushnell, BSG]

On Thu, Mar 13, 2014 at 7:18 PM, Shawn Milochik <sh...@milochik.com> wrote:

The pattern I see is highly valuing terse code. I think that's good when it makes a function more elegant, and bad when it makes "nodePointer" into "np" due to readability, to glean an example from the page above. When code is read more than it is written, especially by more people than just the author, I just think it makes it a lot harder than it has to be.

I think the point is that in this declaration:

var nodePointer *node

you're stuttering. There is nothing better about it, and brevity is an advantage, so in a tie, brevity should win. As Andrew Gerrand points out, notice the reference to "distance from declaration".

The way I usually express this when helping newcomers to the language adapt to its style, is to remind them that there isn't much value for local variables to repeating the name of the type in the variable.

Thomas 

[Gyepi SAM]

On Thu, Mar 13, 2014 at 06:25:29PM -0700, Caleb Spare wrote:
> The section titled "Variable names" in this article
>
> http://doc.cat-v.org/bell_labs/pikestyle
>
> documents some of the background ideas. The details differ slightly
> but I think it's representative of the philosophy behind some of the
> naming.

I highly recommend reading the whole article. "Function pointers" reads
like a prescient elucidation of the underlying philosophies of Go interfaces.

I also recommend Kernighan and Pike's "Practice of Programming" book.
It's long been a favorite of mine. Alas, I am in South Africa now and
failed to pack my copy. However, I did bring Bentley's "Programming Pearls",
also highly recommended, so I am not wholly bereft of good company.

-Gyepi