This might just be my Python upbringing, but... am I the only one to be troubled by Go's single-letter words? I've always found Go code very hard to read because it isn't self-descriptive at all.
Depends, if it's self evident in the context what it means, like in a method which is declared as (p *player) Attack, p makes perfect sense (to me) rather than typing 'player' everywhere in the function, just like typing i instead of index.
In short, I don't think there is a particular rule that applies, that said my impression is that a lot of variable names in Go code are typically three letters or at least two, like err, buf, src, dst, ok etc.
Go is a language in the almost-forgotten algebraic tradition (loosely descending Fortran → Algol → BCPL → C → Go), in which people prefer E=mc² to MULTIPLY REST-MASS BY SPEED-OF-LIGHT-IN-A-VACUUM BY SPEED-OF-LIGHT-IN-A-VACUUM GIVING ENERGY.
When you have a strong static type system like Go has, you don't need descriptive names that much, because even single letter variable names are evident, because the declarations are there, close to the variable names. It needs a bit of getting used to if you only programmed dynamic or scripting languages.
> you don't need descriptive names that much, because even single letter variable names are evident
That's an annoying lie, and makes codebases in languages with genuinely strong static type systems (e.g. Haskell) much harder to read than necessary.
Hell C#'s type system is stronger than Go's, yet there is no such prevalence of meaningless variable names (first one comes in at #23, Go has 7 single-letter variable names in the top 23)
Still, I think GP's comment is interesting. I do agree that type name and variable/argument name can be redundant in statically typed languages, such as c++ or java. (I've never used Go)
For example,
int getAge(Person p);
is clear enough, whereas
int getAge(Person person) ;
is redundant.
Haskell does type inference, so even if types are static they are not explicit. That's why you still need explicit variable names.
I think that depends on the length getAge(). If it's 3 lines, 'p' probably is fine. If it's 200 -- which, perhaps it shouldn't be but that's another issue -- then person is probably a better choice because you may lose the original context as you scan the method.
Also in Java if you use intellij then you'll probably get 'person' as an autocomplete, which actually makes it roughly as easy to type out as 'p', (and a better choice if your entire team has standardized on intellij.)
> I do agree that type name and variable/argument name can be redundant in statically typed languages, such as c++ or java.
Except neither exposes that pattern (they essentially have only one such variable in their top list, and it's "i"). And I already mentioned C# which is very similar to Java.
> is redundant.
I'm not saying single-letter variables (or no variable at all which is also possible in Haskell) is universally bad, I'm saying it is disturbing to find how absolutely ubiquitous it is in Go. Variable names are sometimes redundant, that is not a universal constant. That redundancy is a factor of the expressiveness of the type system, that's hardly a claim of fame of Go.
> Haskell does type inference, so even if types are static they are not explicit.
Go has local type inference, and leveraging Haskell's global type inference is usually recommended against.
> That's why you still need explicit variable names.
My background is scientific and systems programming in C and C++. Currently I write a lot of Python for my job and a lot of Rust for my spare time hobby programming, which consists of things like writing a BLAS, reimplementing other C and C++ projects, etc. So I haven't only programmed in dynamic or scripting languages.
I strongly disagree with the assertion regarding single letter variables. I would gently correct a junior programmer who tried to do that and I would chew the hell out of a senior programmer if he tried it. In any language.
