Hacker News Reader

Comment by Walkman | Hacker News Reader

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.

View on HN

> 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 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.

No, it is not.

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.)

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.

> It needs a bit of getting used to if you only programmed dynamic or scripting languages.

I'm an embedded C developer. Our shop doesn't let single-letter variables pass in code review.

Sounds like a good shop! :)

Even for loop variables I tend to use `idx` these days in languages without smarter constructs. Just slightly better and more readable for no effort.

I disagree, we're so used to reading i that the (actually less phonetic) idx is really slightly harder to read.

I take my bikesheds green, thank you.

Reply on news.ycombinator.com