4 ms·
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 wha
by 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 agoI 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 agoI 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.