4 ms·

We had configurability in early versions of gofmt but realized it was a mistake and kinda missed the whole point of having a code formatter, so we removed them.

mrkgnao 10y ago
While I understand the reasons for this (especially with the culture, for lack of a better word, around Go), I feel like this is a step backward in general. The "standard" Haskell formatter, hindent, did something similar. I found the maintainer's behavior admirable -- the style that was agreed on was very different from his own, but it was what he saw after analyzing publicly available code -- but what's the problem with custom formats if they're consistent across a whole codebase?
- weberc2 10y ago
  In the case of Go, it's really advantageous to be able to jump into anyone's project and be able to read it without the additional impedance of adjusting to the new formatting model. I didn't think this would be that significant until I started participating in the Go community. This works together with Go's reduced feature set, so everyone's code ends up looking very similar.
- jaredklewis 10y ago
  What's the advantage of project specific, custom formats?
  - gknoy 10y ago
    It allows everyone in your company's dev organization share a common `standard` of JS style, which you have agreed on, even if it differs slightly in the way it bikesheds things like single-vs-double quotes or the presence of semicolons. (I mention `standard` because we use it as the basis for our linting rules, and would LOVE to use prettier to reformat our code.)
- dilap 10y ago
  it's something that doesn't matter that you don't ever have to worry about again. it's a huge win.
rattray 10y ago
The problem with doing the same in JS is that the language has been around much longer, and wasn't designed for use with a formatter. ASI failures is a great example. Prettier has so far resisted configuration wherever possible; it has 8 options, compared with eslint's 260+.

mrkgnao 10y ago

While I understand the reasons for this (especially with the culture, for lack of a better word, around Go), I feel like this is a step backward in general. The "standard" Haskell formatter, hindent, did something similar. I found the maintainer's behavior admirable -- the style that was agreed on was very different from his own, but it was what he saw after analyzing publicly available code -- but what's the problem with custom formats if they're consistent across a whole codebase?

weberc2 10y ago
In the case of Go, it's really advantageous to be able to jump into anyone's project and be able to read it without the additional impedance of adjusting to the new formatting model. I didn't think this would be that significant until I started participating in the Go community. This works together with Go's reduced feature set, so everyone's code ends up looking very similar.
jaredklewis 10y ago
What's the advantage of project specific, custom formats?
- gknoy 10y ago
  It allows everyone in your company's dev organization share a common `standard` of JS style, which you have agreed on, even if it differs slightly in the way it bikesheds things like single-vs-double quotes or the presence of semicolons. (I mention `standard` because we use it as the basis for our linting rules, and would LOVE to use prettier to reformat our code.)
dilap 10y ago
it's something that doesn't matter that you don't ever have to worry about again. it's a huge win.

rattray 10y ago

The problem with doing the same in JS is that the language has been around much longer, and wasn't designed for use with a formatter. ASI failures is a great example. Prettier has so far resisted configuration wherever possible; it has 8 options, compared with eslint's 260+.