5 ms·

Personally, I think long lines should never be hard-wrapped; let the editor wrap them. gofmt was a revolutionary social achievement: it got a huge number of pe

by dilap 9y ago

Personally, I think long lines should never be hard-wrapped; let the editor wrap them. gofmt was a revolutionary social achievement: it got a huge number of people to basically all format their code the same. That had never been achieved before; prior to Go doing it, I would not have even thought it would be possible. (Obviously, not revolutionary in any sort of technical sense.)

pcwalton 9y ago
It's clearly been done before. Python, for example, has mandatory indentation, so there's huge pressure for everyone to indent the same so that code can be copied around. Going back further, you have languages like Fortran in which column numbers were significant. Having the editor wrap lines is contrary to standard practice in pretty much every other language. It requires extra editor configuration for no real benefit other than making gofmt a shorter program. Besides, editors don't wrap lines as nicely as a good pretty printer can. Again, look at clang-format: the heuristics it applies in order to apply a maximum line width are very carefully thought out.
- dilap 9y ago
  Python code is not even close to consistently formatted! You see people using 2 space indents, 4 space indents, tabs... Though, Python does do a better job than many languages of providing style guidance (pep 8 iirc), and I don't really see people do wacky stuff like messing with where to put space around parens. &c. Can't speak to Fortran. Thinking about it, maybe languages like J or APL are always consistently formatted by being so dense there's no room for extraneous formatting? But certainly for C-like languages I've used, just getting people on the same team to all use the same format was a struggle, much less the whole company, much much less the whole world. So in that way, gofmt definitely feels revolutionary to me.
  - pcwalton 9y ago
    > But certainly for C-like languages I've used, just getting people on the same team to all use the same format was a struggle, much less the whole company, much much less the whole world. clang-format has really changed the game here. It's commonplace in large projects to run it on every commit. There is a difference between C and C++ formatting and Go formatting, and it's that Go had gofmt from the start and has always had large social pressure to conform to it. Contrary to popular sentiment, I'm not sure that this is an unmitigated good, though. The reason is that clang-format was designed to mimic the existing style that emerges when programmers manually format code for maximum readability. This forced clang-format to consider comment formatting, line length, argument bin packing, etc. It had to be good, or else it wouldn't get use. On the other hand, because gofmt was guaranteed to get lots of use no matter what, there was less pressure for the result to be readable. This shows up in decisions like the lack of a line length limit.
    - dilap 9y ago
      (That's cool to hear about clang-format; I've been out the C++ game for a while, except for the occasional nostalgic prog comp.) Well, again, I personally don't think line limit should be part of the code style -- it's really handy to be able to split or not split emacs buffers and have the code spill out to take up the space, wrapping dynamically. If the code hard-wraps, you're just stuck w/ that single decision. It's annoying. Regarding Go's style more generally: Yeah, my own personal pref would be much denser that gofmt, but I happily submit for the consistency. I just don't think style really matters that much (within the realm of reasonable, which gofmt certainly is): the important thing is consistency. (By the way, a nice side-effect of consistency: you can easily grep for a particular thing w/ confidence w/o having to try to take into account all the possible stylistic variations.)
  - pjmlp 9y ago
    > But certainly for C-like languages I've used, just getting people on the same team to all use the same format was a struggle, much less the whole company, much much less the whole world. We were using indent with CVS pre-commit hooks in 1999, hardly revolutionary.
    - dilap 9y ago
      i can't imagine being happy w/ 1999-era indent autoformatting my code... but yeah, team style was definitely a solvable problem. global style, manifestly was not solved!
      - pjmlp 9y ago
        External libraries are binary dependencies, I don't care one second which style they use to write them.
        dilap 9y ago
        Obviously it's not, like, a world-shattering problem, but I think there is a real, if small, overhead, to switching between different styles when looking at code. I also just happen to really like things neat a tidy. Final minor nice thing about having a fixed style: you can grep with confidence, without having to try to encode stylistic variations in the regex.
      - gkya 9y ago
        I don't get what's wrong with multiple styles.

by dilap 9y ago

pcwalton 9y ago

It's clearly been done before. Python, for example, has mandatory indentation, so there's huge pressure for everyone to indent the same so that code can be copied around. Going back further, you have languages like Fortran in which column numbers were significant. Having the editor wrap lines is contrary to standard practice in pretty much every other language. It requires extra editor configuration for no real benefit other than making gofmt a shorter program. Besides, editors don't wrap lines as nicely as a good pretty printer can. Again, look at clang-format: the heuristics it applies in order to apply a maximum line width are very carefully thought out.

dilap 9y ago
Python code is not even close to consistently formatted! You see people using 2 space indents, 4 space indents, tabs... Though, Python does do a better job than many languages of providing style guidance (pep 8 iirc), and I don't really see people do wacky stuff like messing with where to put space around parens. &c. Can't speak to Fortran. Thinking about it, maybe languages like J or APL are always consistently formatted by being so dense there's no room for extraneous formatting? But certainly for C-like languages I've used, just getting people on the same team to all use the same format was a struggle, much less the whole company, much much less the whole world. So in that way, gofmt definitely feels revolutionary to me.
- pcwalton 9y ago
  > But certainly for C-like languages I've used, just getting people on the same team to all use the same format was a struggle, much less the whole company, much much less the whole world. clang-format has really changed the game here. It's commonplace in large projects to run it on every commit. There is a difference between C and C++ formatting and Go formatting, and it's that Go had gofmt from the start and has always had large social pressure to conform to it. Contrary to popular sentiment, I'm not sure that this is an unmitigated good, though. The reason is that clang-format was designed to mimic the existing style that emerges when programmers manually format code for maximum readability. This forced clang-format to consider comment formatting, line length, argument bin packing, etc. It had to be good, or else it wouldn't get use. On the other hand, because gofmt was guaranteed to get lots of use no matter what, there was less pressure for the result to be readable. This shows up in decisions like the lack of a line length limit.
  - dilap 9y ago
    (That's cool to hear about clang-format; I've been out the C++ game for a while, except for the occasional nostalgic prog comp.) Well, again, I personally don't think line limit should be part of the code style -- it's really handy to be able to split or not split emacs buffers and have the code spill out to take up the space, wrapping dynamically. If the code hard-wraps, you're just stuck w/ that single decision. It's annoying. Regarding Go's style more generally: Yeah, my own personal pref would be much denser that gofmt, but I happily submit for the consistency. I just don't think style really matters that much (within the realm of reasonable, which gofmt certainly is): the important thing is consistency. (By the way, a nice side-effect of consistency: you can easily grep for a particular thing w/ confidence w/o having to try to take into account all the possible stylistic variations.)
- pjmlp 9y ago
  > But certainly for C-like languages I've used, just getting people on the same team to all use the same format was a struggle, much less the whole company, much much less the whole world. We were using indent with CVS pre-commit hooks in 1999, hardly revolutionary.
  - dilap 9y ago
    i can't imagine being happy w/ 1999-era indent autoformatting my code... but yeah, team style was definitely a solvable problem. global style, manifestly was not solved!
    - pjmlp 9y ago
      External libraries are binary dependencies, I don't care one second which style they use to write them.
      - dilap 9y ago
        Obviously it's not, like, a world-shattering problem, but I think there is a real, if small, overhead, to switching between different styles when looking at code. I also just happen to really like things neat a tidy. Final minor nice thing about having a fixed style: you can grep with confidence, without having to try to encode stylistic variations in the regex.
    - gkya 9y ago
      I don't get what's wrong with multiple styles.