4 ms·

First, thanks for putting the work in on prettier! It's a great tool, and it's helping a lot of devs & teams. I find your approach much more reasonable than th

First, thanks for putting the work in on prettier! It's a great tool, and it's helping a lot of devs & teams. I find your approach much more reasonable than the one outlined in the article, which to me feels like complexity for complexity's sake. There might be some minor win to breaking lines by analyzing billions of possibilities, but it just seems like overkill, and it's certainly not predictable for the programmer.

skybrian 8y ago
As another alternative, gofmt solved it a different way, by not having a limit on line length. I haven't seen it add line breaks at all.
- vjeux 8y ago
  gofmt took a different approach where it respects the author's line breaks. So the following are all going to remain as is with gofmt: f(a, b) f( a, b) f(a, b, ) f(a, b) f( a, b, ) My original motivation for prettier was this particular example where I was sick of having to add/remove all those newlines when the line would go below or above 80 columns. So prettier only allows the following two forms and will format code for you as you save: f(a, b) f( a, b, )
  - skybrian 8y ago
    Well okay, but this raises the question of why code needs to always fit within 80 columns. The Go developers decided that it doesn't, and it's fine to check in the code as-is. (In particular, automatic refactoring tools don't need to wrap lines when they get longer.) And everything seems to have worked out fine. It's not the only way to do it, but I think it's interesting how getting everyone to agree that a problem doesn't need solving sometimes simplifies things a lot.
    - bradleyjg 8y ago
      If you do code reviews and your code reviewers take thier role seriously, and so will push back with comments like “this is hard to read, consider breaking it into two lines” then you don’t need automated enforcement. But if code reviewers look for sufficient units tests, obvious errors, and then dash off a LGTM, software style enforcement is second best.
      - skybrian 8y ago
        In practice, this doesn't come up in review and Go code is quite readable anyway. Apparently people just don't need much help to get line lengths more or less right.
    - vjeux 8y ago
      You want to break --at some point--. The question is, who decides where to break? For gofmt, they decided that the person writing the code is going to make this decision everywhere. For prettier, we decided that the tool was going to make that decision, so that the humans don't have to. If we want to do it automatically, we need to figure out an algorithm to do that. It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine. A lot of people (myself included) tried to use different algorithms but couldn't beat that heuristic. If you know of a better way, please let me know :)
      - mbell 8y ago
        > It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine. I'm not sure what corpus was used to determine that heuristic (nor what tab size). But it would trash a lot the projects I work on.
        spraak 8y ago
        Are these projects still JS?
        8y ago
- jaggederest 8y ago
  I would just have it raise an error or warning, but maybe that's me. My first questions when a problem starts to spiral are "Do we really need to solve this problem? And if so, do we really need to solve it right now?"

skybrian 8y ago

As another alternative, gofmt solved it a different way, by not having a limit on line length. I haven't seen it add line breaks at all.

vjeux 8y ago
gofmt took a different approach where it respects the author's line breaks. So the following are all going to remain as is with gofmt: f(a, b) f( a, b) f(a, b, ) f(a, b) f( a, b, ) My original motivation for prettier was this particular example where I was sick of having to add/remove all those newlines when the line would go below or above 80 columns. So prettier only allows the following two forms and will format code for you as you save: f(a, b) f( a, b, )
- skybrian 8y ago
  Well okay, but this raises the question of why code needs to always fit within 80 columns. The Go developers decided that it doesn't, and it's fine to check in the code as-is. (In particular, automatic refactoring tools don't need to wrap lines when they get longer.) And everything seems to have worked out fine. It's not the only way to do it, but I think it's interesting how getting everyone to agree that a problem doesn't need solving sometimes simplifies things a lot.
  - bradleyjg 8y ago
    If you do code reviews and your code reviewers take thier role seriously, and so will push back with comments like “this is hard to read, consider breaking it into two lines” then you don’t need automated enforcement. But if code reviewers look for sufficient units tests, obvious errors, and then dash off a LGTM, software style enforcement is second best.
    - skybrian 8y ago
      In practice, this doesn't come up in review and Go code is quite readable anyway. Apparently people just don't need much help to get line lengths more or less right.
  - vjeux 8y ago
    You want to break --at some point--. The question is, who decides where to break? For gofmt, they decided that the person writing the code is going to make this decision everywhere. For prettier, we decided that the tool was going to make that decision, so that the humans don't have to. If we want to do it automatically, we need to figure out an algorithm to do that. It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine. A lot of people (myself included) tried to use different algorithms but couldn't beat that heuristic. If you know of a better way, please let me know :)
    - mbell 8y ago
      > It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine. I'm not sure what corpus was used to determine that heuristic (nor what tab size). But it would trash a lot the projects I work on.
      - spraak 8y ago
        Are these projects still JS?
        8y ago
jaggederest 8y ago
I would just have it raise an error or warning, but maybe that's me. My first questions when a problem starts to spiral are "Do we really need to solve this problem? And if so, do we really need to solve it right now?"