Hacker News Reader

Comment by nahname | Hacker News Reader

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

View on HN

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.

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.

Reply on news.ycombinator.com