Hacker News Reader

Comment by shockzzz | Hacker News Reader

It's not what this line does, but rather what it doesn't do.

In the context of reading someone else's source code, the variable name "a" is inadequate, and I've seen it in many Golang codebases. It's like intentionally obtuse code.

Maybe I haven't read enough Go code in the wild, but it really feels like the C days. Yes, it's GC'd, and that makes a difference. Yet I can't help but wonder how much easier it is to read code from the Python or Ruby communities. I'd even go as far to say that it's easier to read code from the Javascript community.

View on HN

`a` is not the bestest name in that func, but it's internal (not visible to clients) and it's fairly obvious what it does in the context. Reading Go code everyday, I'm quite used to short variable names like that and I don't find it confusing. Although I did read code in the stdlib that's all bunch of 1-letter vars and was having a hard time following, and in that example you point out, I'd have prefered `app` to `a`.

Maybe this presentation may help you:

http://talks.golang.org/2014/names.slide#1

Doesn't make short variable names right. How do long variable names obscure code!! That's insane. There are many, many ways to obscure code, and there many ways to make it clear. Long-names is one of them.

Overly long variable names is just as much of a hinderence as variable names that don't give enough info.

Your "complaint" of go actually have nothing to do with Go itself...

In my opinion, a is an great variable name. Especially when it is used after calling a function like newApp(...). I may have picked a different name for newApp but it was still clear to me what it did.

I think calling it "a great variable name" is being a touch excessive. You are right that that it's clear from the code what it is, but it's also definitely not a great variable name.

Personally I think single character variable names are over used in Go as well, but at least they're generally restricted to the smallest of functions (eg struct methods), or instances where a longer name wouldn't be more descriptive (eg inside for loops (for i := 0), or b[], byte arrays.).

However in this specific example, I think "a := NewApp(server)" is both readable and overly terse. So I do find myself agreeing with the OP in their example.

> You are right that that it's clear from the code what it is, but it's also definitely not a great variable name.

I have two metrics for variable names. First, is it clear what the variable is? You say yes. Second, is it not obnoxious to type? Clearly not.

So, at least by my metrics, it's a great variable name.

Yeah I understand. It goes both ways. It's an opinion. "Great" probably wasn't a great word to use, but I personally don't have any issue with the line of code since it was easy to understand.

I've looked at a lot of other people's Go code and I have had no issue with 1 character variable names, but maybe that is just me. The methods/functions is generally small enough that it is obvious to me what is happening.

Reply on news.ycombinator.com