4 ms·

You may as well say variables are bad because people are bad at naming variables. I mean, yeah? I don't call my channels "chan", I call them "outputChannel" o

You may as well say variables are bad because people are bad at naming variables. I mean, yeah? I don't call my channels "chan", I call them "outputChannel" or "inputChannel" or "foobarProducer" or "twiddleListeners" or whatever.

inhumantsar 2y ago
it's idiomatic in go to use short names like chan though. I ignore that personally and use names like yours, but it's not been especially common in the go code or docs I've seen.
- bcrosby95 2y ago
  Copying docs like this as idiomatic code seems problematic in any language. The docs have no clue what your domain is and couldn't give a sensible name for a variable in it. For example, lets look at "string". Most examples are gonna just call it a "str" or even "s". But if what you have is someone's name you should get called out for calling it a "str" rather than "name". You shouldn't name all your mathy variables x, y, i, j. You shouldn't name your channels "chan" or "c". Unless its just generic channel code. I don't mind short domain variable names. But "chan" isn't that. It's like calling all your ints "num" or all your strings "str".
- quacker 2y ago
  > it's idiomatic in go to use short names like chan though There's a linter which I like[1] that checks variable name length based on the scope of its usage. The idea is a variable name can be short if it is used in a small lexical scope (e.g. a function parameter in a one-line function) because it won't affect readability much. But names should be descriptive if used in a larger scope (e.g. a constant used across a file). 1. https://github.com/blizzy78/varnamelen https://github.com/blizzy78/varnamelen
  - inhumantsar 2y ago
    oh this sounds great! thanks for sharing
zaphirplane 2y ago
> outputChannel … inputChannel Channels are read/write. What’s the difference between an input and output ch
- bcrosby95 2y ago
  It's in how you use it. One piece of code's output channel might be another piece of code's input channel.

inhumantsar 2y ago

it's idiomatic in go to use short names like chan though. I ignore that personally and use names like yours, but it's not been especially common in the go code or docs I've seen.

bcrosby95 2y ago
Copying docs like this as idiomatic code seems problematic in any language. The docs have no clue what your domain is and couldn't give a sensible name for a variable in it. For example, lets look at "string". Most examples are gonna just call it a "str" or even "s". But if what you have is someone's name you should get called out for calling it a "str" rather than "name". You shouldn't name all your mathy variables x, y, i, j. You shouldn't name your channels "chan" or "c". Unless its just generic channel code. I don't mind short domain variable names. But "chan" isn't that. It's like calling all your ints "num" or all your strings "str".
quacker 2y ago
> it's idiomatic in go to use short names like chan though There's a linter which I like[1] that checks variable name length based on the scope of its usage. The idea is a variable name can be short if it is used in a small lexical scope (e.g. a function parameter in a one-line function) because it won't affect readability much. But names should be descriptive if used in a larger scope (e.g. a constant used across a file). 1. https://github.com/blizzy78/varnamelen https://github.com/blizzy78/varnamelen
- inhumantsar 2y ago
  oh this sounds great! thanks for sharing

zaphirplane 2y ago

> outputChannel … inputChannel Channels are read/write. What’s the difference between an input and output ch

bcrosby95 2y ago
It's in how you use it. One piece of code's output channel might be another piece of code's input channel.