4 ms·

This looks really nice. One of my favourite things about Golang is the use of gofmt and the resulting consistency of all Go programs. The idea of parsing the co

by K0nserv 10y ago

This looks really nice. One of my favourite things about Golang is the use of gofmt and the resulting consistency of all Go programs. The idea of parsing the code to AST representation and then printing it back as source is brilliant, all though it can mess stuff up like the chaining of `.then` as mentioned in the post.

pcwalton 10y ago
gofmt doesn't solve the hard problem that this blog post (and Wadler's paper) is about. From the article: "There's an extremely important piece missing from existing styling tools: the maximum line length." gofmt's decision to not bother to require a line length may work somewhat for Go (which tends to encourage short lines by virtue of lacking expressiveness), but it doesn't work for lots of other languages, including JavaScript.
- K0nserv 10y ago
  Yeah that's a good point. I was referring more the general idea of enforcing style by parsing the code and reconstructing the source from the AST though. This is a better method than the linter approach that you get with eslint for example.
- Strom 10y ago
  The fact that gofmt doesn't enforce some arbitrary line length is a blessing. I have a modern widescreen monitor and I use a maximized window text editor. I have no problem with 200 char length lines. I'm more easily annoyed by 80 (or 60, like in this case) char limits, as if I was viewing this code on punch cards.
  - Manishearth 10y ago
    It can be configurable. The rust community for example sticks to 100 or 120 lines (and rustfmt lets you choose). I have big screens but side by side diffs on unformatted code on GitHub are always wrapped. Plus I often split my screen. Not everyone uses maximized windows all the time, and in a shared codebase sometimes you want to try and cater to everyone.
  - pcwalton 10y ago
    > The fact that gofmt doesn't enforce some arbitrary line length is a blessing. You don't have an infinitely long screen. You have some line length limit.
    - flukus 10y ago
      It's infinitely scrollable though. Scrolling horizontally sometimes isn't a bad fallback.
      - pcwalton 10y ago
        Scrolling horizontally interrupts flow like nothing else! 99% of all software projects have a de facto or de jure line length limit for a reason.
    - stymaar 10y ago
      You don't usually code for one screen since you're not generally coding for yourself alone. IMHO unlimited line length + editor soft-wrap is the best way to deal with the problem since it automatically adjust the size to the reader's screen. Same for tabs for indentation[1], that allows the reader to set its own indentation width depending on its own preferences. I don't really understand why people keep using spaces + fixed line length. Old habits die hard I think. [1] tabs for indentation, space for aligning
  - jayrox 10y ago
    That's exactly how I feel about it. Line length is something I couldn't care less about. If it makes sense to be on one line, then it should be. Otherwise, create the new line where it does make sense.
  - fanf2 10y ago
    I like to divide my screen into multiple windows each 80 or 90 columns wide, so that I can see several source files at the same time, or code and documentation and shell windows. Line length limits help me to make really effective use of big screens.
- flukus 10y ago
  Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.
  - Manishearth 10y ago
    Theoretically, an editor could. I have yet to see one that does this well. Most do dumb wrapping, with no language sensitivity. I think it's just a matter of programmer habit now -- folks expect their editor to mirror the code without formatting tweaks. It gets confusing when you realize that programmers may insert their own indentation and wrapping, and sometimes you want to make this part of the actual file, and sometimes you want to remove it before serializing.
    - flukus 10y ago
      I've been pretty happy with vim and "set breakindent" where the broken line is indented to the parent one. I pretty frequently work with small views of a file.
  - pcwalton 10y ago
    > Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space. Because making the line wrapping nice requires deep syntax-aware editor integration. Most languages try to be at least somewhat plain-text-editor-friendly.
    - flukus 10y ago
      > Because making the line wrapping nice requires deep syntax-aware editor integration. Why does it need to be syntax aware?
      - eddyb 10y ago
        Think what happens when you break a line comment (or a string, in languages where it can't span several lines). And that's an easy example at that.
richie5um 10y ago
I completely agree. What is, for most programming languages / code, a huge waste of time and huge amount of annoyance becomes something you no longer have to deal with. Having choices can be nice, but it introduces a huge amount of cognitive load. And, really, if we all just use the same format, we'll all (eventually) get used to it. We really do have better things to deal with than formatting style.
- icebraining 10y ago
  It also helps if you want to write code conversion tools, like gofix. I once stopped writing such a tool for a Python project because it was a pain trying to change only the affected lines, while keeping the idiosyncratic syntax of the rest of the files unaffected. (By the way, for people trying to do the same, I recommend the redbaron library, which makes it much easier to handle: https://github.com/PyCQA/redbaron https://github.com/PyCQA/redbaron)

by K0nserv 10y ago

pcwalton 10y ago

gofmt doesn't solve the hard problem that this blog post (and Wadler's paper) is about. From the article: "There's an extremely important piece missing from existing styling tools: the maximum line length." gofmt's decision to not bother to require a line length may work somewhat for Go (which tends to encourage short lines by virtue of lacking expressiveness), but it doesn't work for lots of other languages, including JavaScript.

K0nserv 10y ago
Yeah that's a good point. I was referring more the general idea of enforcing style by parsing the code and reconstructing the source from the AST though. This is a better method than the linter approach that you get with eslint for example.
Strom 10y ago
The fact that gofmt doesn't enforce some arbitrary line length is a blessing. I have a modern widescreen monitor and I use a maximized window text editor. I have no problem with 200 char length lines. I'm more easily annoyed by 80 (or 60, like in this case) char limits, as if I was viewing this code on punch cards.
- Manishearth 10y ago
  It can be configurable. The rust community for example sticks to 100 or 120 lines (and rustfmt lets you choose). I have big screens but side by side diffs on unformatted code on GitHub are always wrapped. Plus I often split my screen. Not everyone uses maximized windows all the time, and in a shared codebase sometimes you want to try and cater to everyone.
- pcwalton 10y ago
  > The fact that gofmt doesn't enforce some arbitrary line length is a blessing. You don't have an infinitely long screen. You have some line length limit.
  - flukus 10y ago
    It's infinitely scrollable though. Scrolling horizontally sometimes isn't a bad fallback.
    - pcwalton 10y ago
      Scrolling horizontally interrupts flow like nothing else! 99% of all software projects have a de facto or de jure line length limit for a reason.
  - stymaar 10y ago
    You don't usually code for one screen since you're not generally coding for yourself alone. IMHO unlimited line length + editor soft-wrap is the best way to deal with the problem since it automatically adjust the size to the reader's screen. Same for tabs for indentation[1], that allows the reader to set its own indentation width depending on its own preferences. I don't really understand why people keep using spaces + fixed line length. Old habits die hard I think. [1] tabs for indentation, space for aligning
- jayrox 10y ago
  That's exactly how I feel about it. Line length is something I couldn't care less about. If it makes sense to be on one line, then it should be. Otherwise, create the new line where it does make sense.
- fanf2 10y ago
  I like to divide my screen into multiple windows each 80 or 90 columns wide, so that I can see several source files at the same time, or code and documentation and shell windows. Line length limits help me to make really effective use of big screens.
flukus 10y ago
Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.
- Manishearth 10y ago
  Theoretically, an editor could. I have yet to see one that does this well. Most do dumb wrapping, with no language sensitivity. I think it's just a matter of programmer habit now -- folks expect their editor to mirror the code without formatting tweaks. It gets confusing when you realize that programmers may insert their own indentation and wrapping, and sometimes you want to make this part of the actual file, and sometimes you want to remove it before serializing.
  - flukus 10y ago
    I've been pretty happy with vim and "set breakindent" where the broken line is indented to the parent one. I pretty frequently work with small views of a file.
- pcwalton 10y ago
  > Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space. Because making the line wrapping nice requires deep syntax-aware editor integration. Most languages try to be at least somewhat plain-text-editor-friendly.
  - flukus 10y ago
    > Because making the line wrapping nice requires deep syntax-aware editor integration. Why does it need to be syntax aware?
    - eddyb 10y ago
      Think what happens when you break a line comment (or a string, in languages where it can't span several lines). And that's an easy example at that.

richie5um 10y ago

I completely agree. What is, for most programming languages / code, a huge waste of time and huge amount of annoyance becomes something you no longer have to deal with. Having choices can be nice, but it introduces a huge amount of cognitive load. And, really, if we all just use the same format, we'll all (eventually) get used to it. We really do have better things to deal with than formatting style.

icebraining 10y ago
It also helps if you want to write code conversion tools, like gofix. I once stopped writing such a tool for a Python project because it was a pain trying to change only the affected lines, while keeping the idiosyncratic syntax of the rest of the files unaffected. (By the way, for people trying to do the same, I recommend the redbaron library, which makes it much easier to handle: https://github.com/PyCQA/redbaron https://github.com/PyCQA/redbaron)