5 ms·

As a Ruby guy, one thing off putting to me is that what appears to be "idiomatic Go" involves naming things as tersely as possible. Most Go code I look at has

As a Ruby guy, one thing off putting to me is that what appears to be "idiomatic Go" involves naming things as tersely as possible. Most Go code I look at has maybe-usefully named types or interfaces and then they usually go and assign them to something utterly meaningless like 't', 'vt' and so on. Go's official docs and standard libraries seem to reinforce this style choice, and most 3rd party code follows this general C++ style inspiration too. I know I can do what I like in code that I would write, but it seems like I'd be swimming against the current.

film42 13y ago
This has a lot to do with Rob Pike's programming style, as you can see from the plan 9 source: https://github.com/cao-xx/plan-9/blob/master/sys/src/libregexp/regaux.c https://github.com/cao-xx/plan-9/blob/master/sys/src/librege...
melvinmt 13y ago
Yeah, I went a bit overboard with this style in my first go package as well (http://github.com/melvinmt/gt http://github.com/melvinmt/gt) but now I just follow the convention that only variables that are defined in the function signature should have a single letter. Because due to the explicit type hinting, if you use elaborate variable names, you often end up with redundant naming like: database *Database. So db *Database looks a bit nicer in my opinion while it's still very clear what it is.
asdasf 13y ago
>involves naming things as tersely as possible. No it doesn't. It involves naming things appropriately. If you have a 4 line function that does something with a string, that string argument should be named "s". You aren't making it clearer by giving it a longer name. The length of a variable name is proportional to its scope.
- evilduck 13y ago
  I disagree. 's' has no meaning by itself, which means that you have to read all of the context surrounding 's' into your short term memory just to gain any understanding of the single line you may be interested in. That's slow and more work than necessary most of the time. Also, naming things is a habit and a style. Short variable naming leaks out of 4 line methods into any 40 and 400 line methods you may eventually write, and it leaks into the ABIs/APIs of your application. I've rarely seen any code that would use 's' appropriately in a 4 line method that wouldn't hesitate to use it everywhere else inappropriately.
  - asdasf 13y ago
    >'s' has no meaning by itself That is exactly the point. It is just a string. That is the entire context of the variable, there is no more insight to be gained. The more generic a function is, the more generic the argument is, and thus the less context exists to be put in the name. Naming it "thisIsAStringJustSoYouKnowTwiceThatItIsAStringLikeTheTypeAlreadyToldYou" instead of "s" does not provide any benefit. >I've rarely seen any code that would use 's' appropriately in a 4 line method that wouldn't hesitate to use it everywhere else inappropriately. You should read more code. Both go and haskell have tons of examples, as this is standard practice in those languages.
    - deleted 13y ago
      [deleted]
  - jff 13y ago
    Oh come the fuck on. At least to anyone who's written a C program, using "s" for a string argument is absolutely clear. Read the man pages for pretty much every goddamn string function in the standard library; strlen, strcmp, whatever, they call name them either "s" or "s1", "s2" if there are multiple strings. Maybe we should do strlen(const char* theStringThatIsBeingMeasured), that's a lot clearer. Maybe we should expand char to character, and strlen to stringlength, because it might not be clear enough.
    - bsg75 13y ago
      stringlength may not be clear enough. Need some underscores in there to separate the terms, maybe a prefix to indicate the type, and a url to the parameter documentation.
      - pkinsky 13y ago
        Don't bring underscores into this, underscores scan quicker and are aesthetically pleasing! http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5521745 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumb...
- gnaritas 13y ago
  > that string argument should be named "s" That's an opinion a lot of people don't and won't share.
  - asdasf 13y ago
    That's fine. But the point is that it isn't naming things as tersely as possible, it is naming things based on the value the name provides. There is no name you can give to "s" to make it more meaningful or useful. Thus a longer name is not beneficial.
    - gnaritas 13y ago
      > There is no name you can give to "s" to make it more meaningful or useful. Again, an opinion others don't necessarily share. > Thus a longer name is not beneficial. Again, an opinion others don't necessarily share. You seem to have a habit of stating your personal taste as fact; it is not. Some of us always prefer full words as names as a matter of style.
      - asdasf 13y ago
        Repeating the same thing is not productive. Nobody cares about personal taste or what you do or do not prefer. That has nothing to do with the topic.
        gnaritas 13y ago
        Repeating the same thing is not productive. Nobody cares about your personal taste or what you do or do not prefer. That has nothing to do with the topic.
geoka9 13y ago
It has a lot to do with the C/Unix culture of computing. Generally, there's a rule that writing functions longer than a screenfull that have more than ~7 variables is frowned upon - the rationale being that we humans are not too good at tracking more than 7 things at a time. When you stick to these rules, short names for variables become a no-brainer and arguably make code easier to read.
finishingmove 13y ago
I noticed that this is the case in C-like (low-level) programming languages. People seem to name their variables using one letter.

film42 13y ago

This has a lot to do with Rob Pike's programming style, as you can see from the plan 9 source: https://github.com/cao-xx/plan-9/blob/master/sys/src/libregexp/regaux.c https://github.com/cao-xx/plan-9/blob/master/sys/src/librege...

melvinmt 13y ago

Yeah, I went a bit overboard with this style in my first go package as well (http://github.com/melvinmt/gt http://github.com/melvinmt/gt) but now I just follow the convention that only variables that are defined in the function signature should have a single letter. Because due to the explicit type hinting, if you use elaborate variable names, you often end up with redundant naming like: database *Database. So db *Database looks a bit nicer in my opinion while it's still very clear what it is.

asdasf 13y ago

>involves naming things as tersely as possible. No it doesn't. It involves naming things appropriately. If you have a 4 line function that does something with a string, that string argument should be named "s". You aren't making it clearer by giving it a longer name. The length of a variable name is proportional to its scope.

evilduck 13y ago
I disagree. 's' has no meaning by itself, which means that you have to read all of the context surrounding 's' into your short term memory just to gain any understanding of the single line you may be interested in. That's slow and more work than necessary most of the time. Also, naming things is a habit and a style. Short variable naming leaks out of 4 line methods into any 40 and 400 line methods you may eventually write, and it leaks into the ABIs/APIs of your application. I've rarely seen any code that would use 's' appropriately in a 4 line method that wouldn't hesitate to use it everywhere else inappropriately.
- asdasf 13y ago
  >'s' has no meaning by itself That is exactly the point. It is just a string. That is the entire context of the variable, there is no more insight to be gained. The more generic a function is, the more generic the argument is, and thus the less context exists to be put in the name. Naming it "thisIsAStringJustSoYouKnowTwiceThatItIsAStringLikeTheTypeAlreadyToldYou" instead of "s" does not provide any benefit. >I've rarely seen any code that would use 's' appropriately in a 4 line method that wouldn't hesitate to use it everywhere else inappropriately. You should read more code. Both go and haskell have tons of examples, as this is standard practice in those languages.
  - deleted 13y ago
    [deleted]
- jff 13y ago
  Oh come the fuck on. At least to anyone who's written a C program, using "s" for a string argument is absolutely clear. Read the man pages for pretty much every goddamn string function in the standard library; strlen, strcmp, whatever, they call name them either "s" or "s1", "s2" if there are multiple strings. Maybe we should do strlen(const char* theStringThatIsBeingMeasured), that's a lot clearer. Maybe we should expand char to character, and strlen to stringlength, because it might not be clear enough.
  - bsg75 13y ago
    stringlength may not be clear enough. Need some underscores in there to separate the terms, maybe a prefix to indicate the type, and a url to the parameter documentation.
    - pkinsky 13y ago
      Don't bring underscores into this, underscores scan quicker and are aesthetically pleasing! http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5521745 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumb...
gnaritas 13y ago
> that string argument should be named "s" That's an opinion a lot of people don't and won't share.
- asdasf 13y ago
  That's fine. But the point is that it isn't naming things as tersely as possible, it is naming things based on the value the name provides. There is no name you can give to "s" to make it more meaningful or useful. Thus a longer name is not beneficial.
  - gnaritas 13y ago
    > There is no name you can give to "s" to make it more meaningful or useful. Again, an opinion others don't necessarily share. > Thus a longer name is not beneficial. Again, an opinion others don't necessarily share. You seem to have a habit of stating your personal taste as fact; it is not. Some of us always prefer full words as names as a matter of style.
    - asdasf 13y ago
      Repeating the same thing is not productive. Nobody cares about personal taste or what you do or do not prefer. That has nothing to do with the topic.
      - gnaritas 13y ago
        Repeating the same thing is not productive. Nobody cares about your personal taste or what you do or do not prefer. That has nothing to do with the topic.

geoka9 13y ago

It has a lot to do with the C/Unix culture of computing. Generally, there's a rule that writing functions longer than a screenfull that have more than ~7 variables is frowned upon - the rationale being that we humans are not too good at tracking more than 7 things at a time. When you stick to these rules, short names for variables become a no-brainer and arguably make code easier to read.

finishingmove 13y ago

I noticed that this is the case in C-like (low-level) programming languages. People seem to name their variables using one letter.