5 ms·

I really like the horizontal 'Good/Bad' code comparisons in this guide. I didn't realize how horizontal vs. vertical code comparison affects readability; IMO h

I really like the horizontal 'Good/Bad' code comparisons in this guide. I didn't realize how horizontal vs. vertical code comparison affects readability; IMO horizontal is MUCH more readable. Example: https://github.com/uber-go/guide/blob/master/style.md#defer-to-clean-up https://github.com/uber-go/guide/blob/master/style.md#defer-...

kerng 7y ago
Agreed. This makes it much better parsable! Although on the phone I initially didn't realize there was horizontal content/scrolling! Thanks for pointing that out! Very neat.
klabb3 7y ago
+1. It is quite an achievement by Go as a language and/or community to have generally short lines of code where two columns fit in a regular website width. I don't like everything about Go, but it's usually pretty easy on the eyes for this reason.
- apta 7y ago
  I don't think that the prevalence of single letter variable names can be considered an achievement (which is how they get short lines to begin with). It's quite a hindrance to readability. golang as a language does nothing to support shorter lines.
  - morelisp 7y ago
    > golang as a language does nothing to support shorter lines. It does a few things. - Most declarations, including method declarations, take place at the top level. This is unlike most languages which declare methods one level indented along with the object's fields. - Short type definitions (`type T1 T2`) are encouraged and often used for any repeated non-scalar type. This shortens argument specifications and (if a good name was chosen) improves readability. - Anonymous struct fields are shorter both to declare and use. In class-based OO this is often the case for subclasses but not wrappers/facades. Go's approach covers both. - Go linters push people to avoid `if x { ... return a } else { ... return b }` in favor of `if x { ... return a } ... return b`. I actually hate this, but it does keep indentation down. - The lack of exception handling means there is a constant "pressure" to push errors back up manually, via early return if it's locally unhandled or to the top of the current lexical scope of it is. The result is definitely verbose and one of the easiest parts of Go to criticize - but the same pressure results in short (but plentiful) error handling lines. (I do agree the majority of savings comes from short variable names, though I disagree that it affects readability much for the case of _variable names_ - struct fields are another issue...)
    - apta 7y ago
      > - Most declarations, including method declarations, take place at the top level. This is unlike most languages which declare methods one level indented along with the object's fields. You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. > - Short type definitions (`type T1 T2`) are encouraged and often used for any repeated non-scalar type. This shortens argument specifications and (if a good name was chosen) improves readability. Also possible in C++ or Kotlin, among others. > - Anonymous struct fields are shorter both to declare and use. In class-based OO this is often the case for subclasses but not wrappers/facades. Go's approach covers both. This can save lines of code (at the expense of not being able to easily figure out what classes implement or embed other classes or interfaces), but does nothing to shorten lines of code. Same applies to error handling. Returning early can be useful in certain situations, but cause readability issues in others. golang linters did a bad job here as you point out.
      - morelisp 7y ago
        > You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. I don't know what happens in the Kotlin community, but you absolutely find people saying C++ is "less nested" than Java/Python/JavaScript/etc (and claiming it as an advantage and disadvantage depending on their viewpoint). I don't know what you're really arguing with here. Go gives you a construct that makes lines shorter than most other OO languages. It's not "automatic" as it's a feature of the language someone had to design - but regardless it is shorter. > [Short type definitions are] possible in C++ or Kotlin, among others. Again I don't know Kotlin, but no, it's not possible in C++ (at least up through the 11-and-a-bit I work with). The equivalent C++ would be "struct T1 : public T2", plus another line of "{}". And it's rare (for good-ish reasons) to subclass specializations of the default containers rather than wrap them. > [An anonymous structure] does nothing to shorten lines of code. I don't see how this is a debatable point. Not having to specify the field name in the definition is a shorter line than than having to specify it, strictly so. Not having to specify the full path to such an embedded object to call a method or access a field is nearly always shorter (it can be longer if your struct name is longer than your field name would have been and you have an ambiguous resolution - the former happens a lot, the second less, and both in combination even less). > Returning early can be useful in certain situations, but cause readability issues in others. Regardless, it keeps the lines short. You seem to want to argue "Go is ugly", which, fine. But the claim was "Go doesn't do anything to help make shorter lines." It does quite a bit.

kerng 7y ago

Agreed. This makes it much better parsable! Although on the phone I initially didn't realize there was horizontal content/scrolling! Thanks for pointing that out! Very neat.

klabb3 7y ago

+1. It is quite an achievement by Go as a language and/or community to have generally short lines of code where two columns fit in a regular website width. I don't like everything about Go, but it's usually pretty easy on the eyes for this reason.

apta 7y ago
I don't think that the prevalence of single letter variable names can be considered an achievement (which is how they get short lines to begin with). It's quite a hindrance to readability. golang as a language does nothing to support shorter lines.
- morelisp 7y ago
  > golang as a language does nothing to support shorter lines. It does a few things. - Most declarations, including method declarations, take place at the top level. This is unlike most languages which declare methods one level indented along with the object's fields. - Short type definitions (`type T1 T2`) are encouraged and often used for any repeated non-scalar type. This shortens argument specifications and (if a good name was chosen) improves readability. - Anonymous struct fields are shorter both to declare and use. In class-based OO this is often the case for subclasses but not wrappers/facades. Go's approach covers both. - Go linters push people to avoid `if x { ... return a } else { ... return b }` in favor of `if x { ... return a } ... return b`. I actually hate this, but it does keep indentation down. - The lack of exception handling means there is a constant "pressure" to push errors back up manually, via early return if it's locally unhandled or to the top of the current lexical scope of it is. The result is definitely verbose and one of the easiest parts of Go to criticize - but the same pressure results in short (but plentiful) error handling lines. (I do agree the majority of savings comes from short variable names, though I disagree that it affects readability much for the case of _variable names_ - struct fields are another issue...)
  - apta 7y ago
    > - Most declarations, including method declarations, take place at the top level. This is unlike most languages which declare methods one level indented along with the object's fields. You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. > - Short type definitions (`type T1 T2`) are encouraged and often used for any repeated non-scalar type. This shortens argument specifications and (if a good name was chosen) improves readability. Also possible in C++ or Kotlin, among others. > - Anonymous struct fields are shorter both to declare and use. In class-based OO this is often the case for subclasses but not wrappers/facades. Go's approach covers both. This can save lines of code (at the expense of not being able to easily figure out what classes implement or embed other classes or interfaces), but does nothing to shorten lines of code. Same applies to error handling. Returning early can be useful in certain situations, but cause readability issues in others. golang linters did a bad job here as you point out.
    - morelisp 7y ago
      > You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. I don't know what happens in the Kotlin community, but you absolutely find people saying C++ is "less nested" than Java/Python/JavaScript/etc (and claiming it as an advantage and disadvantage depending on their viewpoint). I don't know what you're really arguing with here. Go gives you a construct that makes lines shorter than most other OO languages. It's not "automatic" as it's a feature of the language someone had to design - but regardless it is shorter. > [Short type definitions are] possible in C++ or Kotlin, among others. Again I don't know Kotlin, but no, it's not possible in C++ (at least up through the 11-and-a-bit I work with). The equivalent C++ would be "struct T1 : public T2", plus another line of "{}". And it's rare (for good-ish reasons) to subclass specializations of the default containers rather than wrap them. > [An anonymous structure] does nothing to shorten lines of code. I don't see how this is a debatable point. Not having to specify the field name in the definition is a shorter line than than having to specify it, strictly so. Not having to specify the full path to such an embedded object to call a method or access a field is nearly always shorter (it can be longer if your struct name is longer than your field name would have been and you have an ambiguous resolution - the former happens a lot, the second less, and both in combination even less). > Returning early can be useful in certain situations, but cause readability issues in others. Regardless, it keeps the lines short. You seem to want to argue "Go is ugly", which, fine. But the claim was "Go doesn't do anything to help make shorter lines." It does quite a bit.