4 ms·

The constancy in Go makes this better. I have come to expect `r` to be an io.Reader or http.Request depending on context. There are a few interfaces in Go that

The constancy in Go makes this better. I have come to expect `r` to be an io.Reader or http.Request depending on context. There are a few interfaces in Go that are used heavily and I don't mind that people often use a single character for them. It's the same thing as everyone using `i` for iterators.

bpicolo 4y ago
I just use reader//req. Code is instantly easier to read for me personally and no time has been wasted. It's all preference, of course.
- kevmo314 4y ago
  Sometimes you run into packages called reader which makes for a less fun time using variable names that are also words.
- rlabrecque 4y ago
  This is much nicer for other people coming into this. It's the same problem with spoken language and slang, slang is better if you know it, worse if you don't.
  - dimitrios1 4y ago
    Sorry to be pedantic (well, not really it's M.O. for a hacker news commentor after all, isn't it?) , but as someone who knows a few languages, slang is not an issue with spoken languages at all. You learn a language by full immersion with other speakers, who impart that knowledge unto you. Unless all you are doing is conversing with grammaticians and newscasters, you will pick up on regional and local differences, euphemisms, and slang.
- shepherdjerred 4y ago
  I don't believe so. Imagine you're new to Go and you haven't mentally mapped all of these abbreviations. What would you rather read, `r` or `reader`?
  - jrockway 4y ago
    Designing an API that "stutters" is a very common mistake that many programmers make. reader.Read() is pretty jarring. There is also nothing wrong with naming variables after what they're for instead of what they are. Consider io.Copy(dst, src). That's nicer than io.Copy(reader1, reader2).
    - pindab0ter 4y ago
      But not necessarily nicer than io.Copy(destination, source).
    - shepherdjerred 4y ago
      Sure, so call your reader `file` or `network` or `stream`. Don't call it `r`. Nobody is charging you by the character. It isn't a huge deal when the code is simple, e.g. you create a reader named `r` and in the next line you use it. That's easy to understand. The problem is that the pattern propagates. A few more lines of code are added, the reader is still named `r`. It's name `r` here, so we start putting it in a struct as `r`. Soon enough the codebase is littered with instances of `r`. Not great.
jawzz 4y ago
This makes me wonder: what if there was a language where variable names are determined according to the type, with the option of overriding with a custom name. So a variable of type http.Request would automatically be named “req”, the next one in scope would be “req2”, etc. If you think about it, when you solve a physics problem, for instance, you call every mass “m1”, “m2”, etc. Maybe this would be another step in Go’s direction of conforming style to make code more standard and readable.
- leetrout 4y ago
  This is interesting. The idea of having a standard library of types related to what are effectively program keywords... could be really good. Or hideous like global vars. I wonder if any language has tried this?
- notpushkin 4y ago
  https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation
  - jawzz 4y ago
    Oh cool, thanks for that.
- gbalduzzi 4y ago
  I agree that most types come with a natural variable name. However, in many cases a more descriptive name is way appropriate. On top of my mind: - Multiple variables of the same type. How are you supposed to distinguish between req and req2? Compare it to something like "apiReq" and "cdnReq" - Primitive types, that does not inherently carry a domain value. An integer called "seconds" or "max_offset" has a lot more meaning that one named "num" Forcing such a notation into the language would make impossibile to represent all these cases
  - gogogogogogo 4y ago
    The real question from this example is: why are you creating two http requests in the same scope before using them? I've been writing Go cloud stuff for the better part of a decade and "req" for a request has never been ambiguous because I go ahead and send the request and process the response before sending another one, at which point I can just reassign the variable and let the first one fall out of scope.

bpicolo 4y ago

I just use reader//req. Code is instantly easier to read for me personally and no time has been wasted. It's all preference, of course.

kevmo314 4y ago
Sometimes you run into packages called reader which makes for a less fun time using variable names that are also words.
rlabrecque 4y ago
This is much nicer for other people coming into this. It's the same problem with spoken language and slang, slang is better if you know it, worse if you don't.
- dimitrios1 4y ago
  Sorry to be pedantic (well, not really it's M.O. for a hacker news commentor after all, isn't it?) , but as someone who knows a few languages, slang is not an issue with spoken languages at all. You learn a language by full immersion with other speakers, who impart that knowledge unto you. Unless all you are doing is conversing with grammaticians and newscasters, you will pick up on regional and local differences, euphemisms, and slang.
shepherdjerred 4y ago
I don't believe so. Imagine you're new to Go and you haven't mentally mapped all of these abbreviations. What would you rather read, `r` or `reader`?
- jrockway 4y ago
  Designing an API that "stutters" is a very common mistake that many programmers make. reader.Read() is pretty jarring. There is also nothing wrong with naming variables after what they're for instead of what they are. Consider io.Copy(dst, src). That's nicer than io.Copy(reader1, reader2).
  - pindab0ter 4y ago
    But not necessarily nicer than io.Copy(destination, source).
  - shepherdjerred 4y ago
    Sure, so call your reader `file` or `network` or `stream`. Don't call it `r`. Nobody is charging you by the character. It isn't a huge deal when the code is simple, e.g. you create a reader named `r` and in the next line you use it. That's easy to understand. The problem is that the pattern propagates. A few more lines of code are added, the reader is still named `r`. It's name `r` here, so we start putting it in a struct as `r`. Soon enough the codebase is littered with instances of `r`. Not great.

jawzz 4y ago

This makes me wonder: what if there was a language where variable names are determined according to the type, with the option of overriding with a custom name. So a variable of type http.Request would automatically be named “req”, the next one in scope would be “req2”, etc. If you think about it, when you solve a physics problem, for instance, you call every mass “m1”, “m2”, etc. Maybe this would be another step in Go’s direction of conforming style to make code more standard and readable.

leetrout 4y ago
This is interesting. The idea of having a standard library of types related to what are effectively program keywords... could be really good. Or hideous like global vars. I wonder if any language has tried this?
notpushkin 4y ago
https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation
- jawzz 4y ago
  Oh cool, thanks for that.
gbalduzzi 4y ago
I agree that most types come with a natural variable name. However, in many cases a more descriptive name is way appropriate. On top of my mind: - Multiple variables of the same type. How are you supposed to distinguish between req and req2? Compare it to something like "apiReq" and "cdnReq" - Primitive types, that does not inherently carry a domain value. An integer called "seconds" or "max_offset" has a lot more meaning that one named "num" Forcing such a notation into the language would make impossibile to represent all these cases
- gogogogogogo 4y ago
  The real question from this example is: why are you creating two http requests in the same scope before using them? I've been writing Go cloud stuff for the better part of a decade and "req" for a request has never been ambiguous because I go ahead and send the request and process the response before sending another one, at which point I can just reassign the variable and let the first one fall out of scope.