5 ms·

The thing about configurable vs non-configurable in this case is that when its configurable then people will spend time debating how exactly they should configu

The thing about configurable vs non-configurable in this case is that when its configurable then people will spend time debating how exactly they should configure it.

autarch 2y ago
Yes, that's why I love gofmt. There's nothing to debate!
- jrockway 2y ago
  Helpfully, you can debate between "gofmt", "gofmt -s" and "gofumpt". I actually like how gofumpt formats stuff but ... nobody else on the team would have it, so it would make things worse.
  - autarch 2y ago
    Yeah, there's still a few options. But try running `perltidy --help`. Even that doesn't really give you a sense of how many options there are because many of the options are not booleans, but instead take several enum values indicating which style to choose.
  - dmurray 2y ago
    You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing. I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple tools to collaborate on code.
    - cmcaine 2y ago
      No, you'd likely get unrelated style changes in your commits. Read the gofumpt readme to understand why.
      - dmurray 2y ago
        I see! Seems like neither formatter is completely rigid, and both respect some style decisions made by the programmer, so this level of automated reformatting isn't possible.
    - jaeckel 2y ago
      > [...] nor tooling that makes it a really natural thing to do [...] If we ignore the fact that switching between those two formatters would "break" the formatting: There exist clean&smudge filters in Git, which could accomplish this technically. https://git-scm.com/docs/gitattributes#_filter https://git-scm.com/docs/gitattributes#_filter https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#filters_a https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
- josephg 2y ago
  I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff like that. By removing the maker’s marks, these tools make my code less readable. While, in my opinion, adding practically no value. I’m more than happy for every line of code to have consistent indentation (of course, but it did already). I also don't have a problem with silly but arbitrary formatting choices - like sorting my import lines. But these tools seem to drive so far for consistency that it costs readability. That’s a nope for me. No debate.
  - stavros 2y ago
    These tools, like any tool of the type, bring your code to the 90th percentile. This is good for nine out of ten people, because it improves their code. It's also good for the tenth person, when he has to read the code of the other nine. If you're the tenth person, and you work alone, or with other fastidious people, you won't like the formatter. That's fine, you don't need to use it.
  - autarch 2y ago
    That's fine for your solo projects. It's definitely not okay at work.
    - josephg 2y ago
      Why not? Whats the ROI of making the number of lines that separate functions the same across our entire codebase? That sounds completely pointless.
      - autarch 2y ago
        It's easier to read and refactor code when it's all formatted the same way. Otherwise diffs end up with tons of extraneous noise. Plus it adds needless decisions. If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it? What about when someone leaves the company? Is it free game to reformat everything they wrote? Why do you need to put your mark on code at work? It's not _your_ code. It belongs to the employer. The best work is work that is useful and not an irritant long after you're gone.

The thing about configurable vs non-configurable in this case is that when its configurable then people will spend time debating how exactly they should configure it.

autarch 2y ago

Yes, that's why I love gofmt. There's nothing to debate!

jrockway 2y ago
Helpfully, you can debate between "gofmt", "gofmt -s" and "gofumpt". I actually like how gofumpt formats stuff but ... nobody else on the team would have it, so it would make things worse.
- autarch 2y ago
  Yeah, there's still a few options. But try running `perltidy --help`. Even that doesn't really give you a sense of how many options there are because many of the options are not booleans, but instead take several enum values indicating which style to choose.
- dmurray 2y ago
  You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing. I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple tools to collaborate on code.
  - cmcaine 2y ago
    No, you'd likely get unrelated style changes in your commits. Read the gofumpt readme to understand why.
    - dmurray 2y ago
      I see! Seems like neither formatter is completely rigid, and both respect some style decisions made by the programmer, so this level of automated reformatting isn't possible.
  - jaeckel 2y ago
    > [...] nor tooling that makes it a really natural thing to do [...] If we ignore the fact that switching between those two formatters would "break" the formatting: There exist clean&smudge filters in Git, which could accomplish this technically. https://git-scm.com/docs/gitattributes#_filter https://git-scm.com/docs/gitattributes#_filter https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#filters_a https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
josephg 2y ago
I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff like that. By removing the maker’s marks, these tools make my code less readable. While, in my opinion, adding practically no value. I’m more than happy for every line of code to have consistent indentation (of course, but it did already). I also don't have a problem with silly but arbitrary formatting choices - like sorting my import lines. But these tools seem to drive so far for consistency that it costs readability. That’s a nope for me. No debate.
- stavros 2y ago
  These tools, like any tool of the type, bring your code to the 90th percentile. This is good for nine out of ten people, because it improves their code. It's also good for the tenth person, when he has to read the code of the other nine. If you're the tenth person, and you work alone, or with other fastidious people, you won't like the formatter. That's fine, you don't need to use it.
- autarch 2y ago
  That's fine for your solo projects. It's definitely not okay at work.
  - josephg 2y ago
    Why not? Whats the ROI of making the number of lines that separate functions the same across our entire codebase? That sounds completely pointless.
    - autarch 2y ago
      It's easier to read and refactor code when it's all formatted the same way. Otherwise diffs end up with tons of extraneous noise. Plus it adds needless decisions. If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it? What about when someone leaves the company? Is it free game to reformat everything they wrote? Why do you need to put your mark on code at work? It's not _your_ code. It belongs to the employer. The best work is work that is useful and not an irritant long after you're gone.