95 ms·

The bit about better "errors" for Allman style braces really drives home to me just how proudly opinionated Go is. "We know about this other indent style and ac

by dejawu 9y ago

The bit about better "errors" for Allman style braces really drives home to me just how proudly opinionated Go is. "We know about this other indent style and acknowledge it, but it's WRONG." I really gave Go a good shot, built a project of decent size with it and used it as my go-to first choice for a few others, but every time these little nitpicks come back and make it feel like Go is smacking my hands away from the keyboard. "Bad programmer! You didn't do it the way I wanted you to!" I would love to use a hypothetical "Go++" that's built from the same roots of Go but forgoes its opinionated nature, even if it's at the cost of messier code. Someone somewhere has to be working on that... maybe I should give it a try.

dilap 9y ago
man for me that's such an advantage of Go. i dont think brace style & other style quirks matter that much, but having them be consistent really helps a lot. so just pick one style and be done with it. also, having all code use the same style means you can safely search for semantics just using a syntactic pattern.
- laumars 9y ago
  I completely agree. The dogmatic opinionated approach Go takes grated with me initially but with gofmt automatically "fixing faux pas" and the ease at which I've found reading back old code or other people projects, I've come to realise I've saved more time in the long run due to their opinionated approach. And frankly, there are more important issues with writing code than which line an opening brace should land on.
- __david__ 9y ago
  I think consistency is very overrated by the go community. I read and work on a lot of C code, and styles vary considerably. It's just not hard to read code in different styles. And my main problem is not that `go fmt` enforces a specific style, but that it enforces a specific style that actively harms readability. Defaults are good as long as they are sane, but `go fmt` made some really stupid decisions.
  - dilap 9y ago
    switching between styles isn't the end of the world, but it's not zero cost either (at least for me). knowing i can confidently grep for something w/o having to try to include style variants is nice. my personal style would be more condensed than gofmt, but it doesn't make any choices i think are really stupid. what bugs you out of curiosity?
  - laumars 9y ago
    The thing with readability is that consistency matters more than the specific style chosen as any serious time spent with a specific style will teach you to read the code regardless of the chosen style. This is why Perl developers often defend the readability complaints of the language and why C++ style syntax gained popularity despite Pascal's syntax being arguably more readable. My point is everyone will have their own personal preferences about style guidelines and argue that theirs is the most readable but frankly the most readable is just whatever you spend the most time reading. So you quickly get good at reading other language style guides when you spend time coding in their respective languages
  - baby 9y ago
    Go read OpenSSL's code before they decided to have a consistent style[^1] and come back here [^1]: https://github.com/openssl/openssl/blob/7a71af86ce75751f3cb2e9e9e3f2e0715b39b101/ssl/ssl_rsa.c https://github.com/openssl/openssl/blob/7a71af86ce75751f3cb2...
    - __david__ 9y ago
      The style in that file seems completely self consistent. I don't know what your point is.
      - baby 9y ago
        Browse different files in the repository at that time, not just one file. Different files will have different styles, and awful ones at that.
joobus 9y ago
> forgoes its opinionated nature, even if it's at the cost of messier code Absolutely not. Have you never worked with anyone who just can't adhere to any standards? Go forces that guy at my office to at least get spacing and braces right, even if the rest of his code is lacking.
- pjmlp 9y ago
  I was doing that with indent and CVS plugins back in 2000.
  - sliken 9y ago
    Yes, but it's pretty central to go. If code is posted somewhere for review/comment "Why doesn't this work?", often the first comments is run gofmt on it first. It's generally expected that all commits to code are in the gofmt standard, and there's not even the option to change the format. I suspect if you analyzed all the code on github that go would have much higher compliance with the gofmt standard that you'd find to any other single standard for java or c++. Gofmt is pretty nice, I wouldn't make the same decisions myself, but it's pretty valuable to have all code I see with exactly the same formatting. Additional gofmt uses the same parse as the language and can even parse, modify, and invert to produce a new source file. Similarly it's much easier to write a golang aware editor than most other languages.
RangerScience 9y ago
If I remember correctly, it's actually a consequence of how the parser handles certain circumstances. It's not just arbitrary and enforced.
joeblubaugh 9y ago
The requirement that braces be on the same line is a consequence of the semicolon insertion that the compiler performs. This is also why the error messages confusing when the brace is on the next line. Because a semicolon is inserted whenever the parser encounters an identifer or a token that's not in a special restricted set that includes ( and {, you end up with a semicolon inserted between a control flow statement and the bracket. I suppose the grammar could have been modified to require that control statements include parens, or that the bracket become part of the control statement, but that's also kind of ugly ...

by dejawu 9y ago

dilap 9y ago

man for me that's such an advantage of Go. i dont think brace style & other style quirks matter that much, but having them be consistent really helps a lot. so just pick one style and be done with it. also, having all code use the same style means you can safely search for semantics just using a syntactic pattern.

laumars 9y ago
I completely agree. The dogmatic opinionated approach Go takes grated with me initially but with gofmt automatically "fixing faux pas" and the ease at which I've found reading back old code or other people projects, I've come to realise I've saved more time in the long run due to their opinionated approach. And frankly, there are more important issues with writing code than which line an opening brace should land on.
__david__ 9y ago
I think consistency is very overrated by the go community. I read and work on a lot of C code, and styles vary considerably. It's just not hard to read code in different styles. And my main problem is not that `go fmt` enforces a specific style, but that it enforces a specific style that actively harms readability. Defaults are good as long as they are sane, but `go fmt` made some really stupid decisions.
- dilap 9y ago
  switching between styles isn't the end of the world, but it's not zero cost either (at least for me). knowing i can confidently grep for something w/o having to try to include style variants is nice. my personal style would be more condensed than gofmt, but it doesn't make any choices i think are really stupid. what bugs you out of curiosity?
- laumars 9y ago
  The thing with readability is that consistency matters more than the specific style chosen as any serious time spent with a specific style will teach you to read the code regardless of the chosen style. This is why Perl developers often defend the readability complaints of the language and why C++ style syntax gained popularity despite Pascal's syntax being arguably more readable. My point is everyone will have their own personal preferences about style guidelines and argue that theirs is the most readable but frankly the most readable is just whatever you spend the most time reading. So you quickly get good at reading other language style guides when you spend time coding in their respective languages
- baby 9y ago
  Go read OpenSSL's code before they decided to have a consistent style[^1] and come back here [^1]: https://github.com/openssl/openssl/blob/7a71af86ce75751f3cb2e9e9e3f2e0715b39b101/ssl/ssl_rsa.c https://github.com/openssl/openssl/blob/7a71af86ce75751f3cb2...
  - __david__ 9y ago
    The style in that file seems completely self consistent. I don't know what your point is.
    - baby 9y ago
      Browse different files in the repository at that time, not just one file. Different files will have different styles, and awful ones at that.

joobus 9y ago

> forgoes its opinionated nature, even if it's at the cost of messier code Absolutely not. Have you never worked with anyone who just can't adhere to any standards? Go forces that guy at my office to at least get spacing and braces right, even if the rest of his code is lacking.

pjmlp 9y ago
I was doing that with indent and CVS plugins back in 2000.
- sliken 9y ago
  Yes, but it's pretty central to go. If code is posted somewhere for review/comment "Why doesn't this work?", often the first comments is run gofmt on it first. It's generally expected that all commits to code are in the gofmt standard, and there's not even the option to change the format. I suspect if you analyzed all the code on github that go would have much higher compliance with the gofmt standard that you'd find to any other single standard for java or c++. Gofmt is pretty nice, I wouldn't make the same decisions myself, but it's pretty valuable to have all code I see with exactly the same formatting. Additional gofmt uses the same parse as the language and can even parse, modify, and invert to produce a new source file. Similarly it's much easier to write a golang aware editor than most other languages.

RangerScience 9y ago

If I remember correctly, it's actually a consequence of how the parser handles certain circumstances. It's not just arbitrary and enforced.

joeblubaugh 9y ago

The requirement that braces be on the same line is a consequence of the semicolon insertion that the compiler performs. This is also why the error messages confusing when the brace is on the next line. Because a semicolon is inserted whenever the parser encounters an identifer or a token that's not in a special restricted set that includes ( and {, you end up with a semicolon inserted between a control flow statement and the bracket. I suppose the grammar could have been modified to require that control statements include parens, or that the bracket become part of the control statement, but that's also kind of ugly ...