6 ms·

It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high s

by adamkl 9y ago

It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variable-names https://github.com/golang/go/wiki/CodeReviewComments#variabl...

Teckla 9y ago
I came here to say the same thing, and I'm so relieved I'm not the only one. Looking at those one- and two-letter variable names constantly leaves me scratching my head and wasting time figuring out what they mean.
jpittis 9y ago
I find it really depends. Small variable names for iteration variables and the `this` equivalent in struct methods are fine. As for other situations... I guess it's an art?
carbocation 9y ago
I've mostly interpreted that to use single character names for method receivers and loop variables. I think those are defensible because you know where to find them if you need their definition (in the method definition or in the loop). I don't think that assigning terse names (such as the variable "ra" from the OP) to variables that might be declared anywhere in a function is helpful.
- adamkl 9y ago
  I agree, and the link I posted states as much. I think the problem comes when people take that advice without nuance and think it gives them carte blanche to make everything as obscure as possible. And really, it’s not about whether or not we can understand our own code, but can the future developers who have to maintain it after we leave. I kinda worry that the Go community is creating a lot of unmaintainable code right now.
  - geodel 9y ago
    I see an intrinsic pattern to variable naming in Go and not some randomly assigned single letters. I work on Java code where variables name look like 'reconnectDelayToInitiallyEstablishJMSConnection" Even though very clear name it really exhaust me while reading code like this. Java explicitness things like spreading code over dozens of files and directories for a functionality that could ideally be in 1-2 reasonably sized files. And methods that actually do something instead of calling another methods. So I guess code I deal with is understandable at a method level which finally does something. But overall it is too sprawling to fit everything in mind while looking at a functionality.
    - adamkl 9y ago
      I would just argue for a happy median. Enough to convey intent, without being verbose. Your java example is clearly exhausingly verbose (I’ve seen similar in C#), where it seems in Go it would probably be written: rd := 1000 How is anyone supposed to understand at a glance what this value is for? Why not just: reconnectionDelay := 1000 Intent is clear. And now, I have strayed way too far off topic (I’ve done some flamegraph style debugging in .Net, super useful!), and should probably apologize to the OP.
      - crispinb 9y ago
        (to continue straying for a moment..) perhaps though it best depends on the variable specifics: like how often it appears, how far apart multiple uses are, etc. Some natural limits might be: (1) single letters for extremely local terms whose structural meaning is more salient than denotation (canonical example: loop counter); (2) fully spelled-out terms for globally-significant terms (not necessarily in global scope) whose denotation is crucial (canonical example: an app configuration value). Even two short camel-cased words often seem unnecessarily verbose for a loop counter to me. Whereas an important global config variable might justify the full THIS_IS_WHAT_I_AM_FOR treatment.
  - erik_seaberg 9y ago
    Java went through a phase of not having inner classes, autoboxing, enums, generics, and looping over iterables. The code from that era was burned to the ground for being unreadable shit. This is survivable, if they're motivated to fix the glaring omissions in Go.
- nahname 9y ago
  Though that would still be idiomatic go code. For what it is worth, I do agree with you. Short variable names on a function are a hassle. You have to lookup what they mean, which slows down understanding. n = copy(p, b.buf[b.r:b.w]) Oh better go to the top and see what those are again... https://github.com/golang/go/blob/master/src/bufio/bufio.go#L190 https://github.com/golang/go/blob/master/src/bufio/bufio.go#...
  - dilap 9y ago
    I find to understand a piece of code, I need to know what all the involved variables are, which I'll have to do regardless of long or short names. Once I know what they all are, I find it's easier for me to track them through the function if they have short names. Something java style like numBytesWritten = copy(destinationBuffer, reader.buffer[reader.readPosition:reader.writePosition] is much harder for me to follow.
  - zxcmx 9y ago
    I didn't look at the file but I find that perfectly comprehensible. I can see read & write pointers in a buffer, n as bytes copied. Not sure if p is source or dest w/out looking but my guess is dest? Maybe it's a cultural thing - lots of C code looks like this from Lion's UNIX book onwards. I still find this style easier on the eyes when it's clear from context what is going on. For i/o code this is about as obscure as using "i" for a loop index.
table-delete 9y ago
There's a great rule of thumb coined by Andrew Gerrand: "The greater the distance between a name's declaration and its uses, the longer the name should be." [1] There's no reason to use any more than a single character for a loop variable. Who cares how old the convention is? [1] https://talks.golang.org/2014/names.slide https://talks.golang.org/2014/names.slide

by adamkl 9y ago

Teckla 9y ago

I came here to say the same thing, and I'm so relieved I'm not the only one. Looking at those one- and two-letter variable names constantly leaves me scratching my head and wasting time figuring out what they mean.

jpittis 9y ago

I find it really depends. Small variable names for iteration variables and the `this` equivalent in struct methods are fine. As for other situations... I guess it's an art?

carbocation 9y ago

I've mostly interpreted that to use single character names for method receivers and loop variables. I think those are defensible because you know where to find them if you need their definition (in the method definition or in the loop). I don't think that assigning terse names (such as the variable "ra" from the OP) to variables that might be declared anywhere in a function is helpful.

adamkl 9y ago
I agree, and the link I posted states as much. I think the problem comes when people take that advice without nuance and think it gives them carte blanche to make everything as obscure as possible. And really, it’s not about whether or not we can understand our own code, but can the future developers who have to maintain it after we leave. I kinda worry that the Go community is creating a lot of unmaintainable code right now.
- geodel 9y ago
  I see an intrinsic pattern to variable naming in Go and not some randomly assigned single letters. I work on Java code where variables name look like 'reconnectDelayToInitiallyEstablishJMSConnection" Even though very clear name it really exhaust me while reading code like this. Java explicitness things like spreading code over dozens of files and directories for a functionality that could ideally be in 1-2 reasonably sized files. And methods that actually do something instead of calling another methods. So I guess code I deal with is understandable at a method level which finally does something. But overall it is too sprawling to fit everything in mind while looking at a functionality.
  - adamkl 9y ago
    I would just argue for a happy median. Enough to convey intent, without being verbose. Your java example is clearly exhausingly verbose (I’ve seen similar in C#), where it seems in Go it would probably be written: rd := 1000 How is anyone supposed to understand at a glance what this value is for? Why not just: reconnectionDelay := 1000 Intent is clear. And now, I have strayed way too far off topic (I’ve done some flamegraph style debugging in .Net, super useful!), and should probably apologize to the OP.
    - crispinb 9y ago
      (to continue straying for a moment..) perhaps though it best depends on the variable specifics: like how often it appears, how far apart multiple uses are, etc. Some natural limits might be: (1) single letters for extremely local terms whose structural meaning is more salient than denotation (canonical example: loop counter); (2) fully spelled-out terms for globally-significant terms (not necessarily in global scope) whose denotation is crucial (canonical example: an app configuration value). Even two short camel-cased words often seem unnecessarily verbose for a loop counter to me. Whereas an important global config variable might justify the full THIS_IS_WHAT_I_AM_FOR treatment.
- erik_seaberg 9y ago
  Java went through a phase of not having inner classes, autoboxing, enums, generics, and looping over iterables. The code from that era was burned to the ground for being unreadable shit. This is survivable, if they're motivated to fix the glaring omissions in Go.
nahname 9y ago
Though that would still be idiomatic go code. For what it is worth, I do agree with you. Short variable names on a function are a hassle. You have to lookup what they mean, which slows down understanding. n = copy(p, b.buf[b.r:b.w]) Oh better go to the top and see what those are again... https://github.com/golang/go/blob/master/src/bufio/bufio.go#L190 https://github.com/golang/go/blob/master/src/bufio/bufio.go#...
- dilap 9y ago
  I find to understand a piece of code, I need to know what all the involved variables are, which I'll have to do regardless of long or short names. Once I know what they all are, I find it's easier for me to track them through the function if they have short names. Something java style like numBytesWritten = copy(destinationBuffer, reader.buffer[reader.readPosition:reader.writePosition] is much harder for me to follow.
- zxcmx 9y ago
  I didn't look at the file but I find that perfectly comprehensible. I can see read & write pointers in a buffer, n as bytes copied. Not sure if p is source or dest w/out looking but my guess is dest? Maybe it's a cultural thing - lots of C code looks like this from Lion's UNIX book onwards. I still find this style easier on the eyes when it's clear from context what is going on. For i/o code this is about as obscure as using "i" for a loop index.

table-delete 9y ago

There's a great rule of thumb coined by Andrew Gerrand: "The greater the distance between a name's declaration and its uses, the longer the name should be." [1] There's no reason to use any more than a single character for a loop variable. Who cares how old the convention is? [1] https://talks.golang.org/2014/names.slide https://talks.golang.org/2014/names.slide