3 ms·

But why should Go enforce it on behalf of everybody? A parser option to not automatically insert semicolons would be all I need, but no. To me, even with super

by musage 9y ago

But why should Go enforce it on behalf of everybody? A parser option to not automatically insert semicolons would be all I need, but no. To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy. > Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself Which then leaves the language to explain why that style is best. Did Google ever do that?

donjoe 9y ago
Go's authors didn't explicitly explain their choice of style, yet they explain why they enforce it: https://golang.org/doc/faq#Is_there_a_Go_programming_style_guide https://golang.org/doc/faq#Is_there_a_Go_programming_style_g... https://golang.org/doc/effective_go.html#formatting https://golang.org/doc/effective_go.html#formatting Style guides are a matter of taste. None is better or worse. Yet, I really don't like discussing about my taste within a team of different tastes. It's like asking someone why he/she'd prefer black coffee over cappuccino. I'd prefer someone (or the language) making a clear decision upon code style and enforcing it rather than ending up with a messy, un-styled code base.
thegeekpirate 9y ago
Official response: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s
- musage 9y ago
  Yeah, that's what I thought.
AnimalMuppet 9y ago
> To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy. To me, they're just harder to spot. I think having them on their own line "frames" the inner block nicely. That said, brace location is not the hill I'm willing to die on. It's a minor thing, not worth getting religious over. For my own code, I'll do it how I want. For a team, though, consistency really does matter. I'll make my case, and then I'll shut up and do what the group decides. (And actually, I think consistency within a file matters more than consistency between files, so I'm fine with "The file author/main maintainer sets the style for the file. If you modify the file, keep the existing style.")

by musage 9y ago

donjoe 9y ago

Go's authors didn't explicitly explain their choice of style, yet they explain why they enforce it: https://golang.org/doc/faq#Is_there_a_Go_programming_style_guide https://golang.org/doc/faq#Is_there_a_Go_programming_style_g... https://golang.org/doc/effective_go.html#formatting https://golang.org/doc/effective_go.html#formatting Style guides are a matter of taste. None is better or worse. Yet, I really don't like discussing about my taste within a team of different tastes. It's like asking someone why he/she'd prefer black coffee over cappuccino. I'd prefer someone (or the language) making a clear decision upon code style and enforcing it rather than ending up with a messy, un-styled code base.

thegeekpirate 9y ago

Official response: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s

musage 9y ago
Yeah, that's what I thought.

AnimalMuppet 9y ago

> To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy. To me, they're just harder to spot. I think having them on their own line "frames" the inner block nicely. That said, brace location is not the hill I'm willing to die on. It's a minor thing, not worth getting religious over. For my own code, I'll do it how I want. For a team, though, consistency really does matter. I'll make my case, and then I'll shut up and do what the group decides. (And actually, I think consistency within a file matters more than consistency between files, so I'm fine with "The file author/main maintainer sets the style for the file. If you modify the file, keep the existing style.")