6 ms·

The Dart formatter sounds really advanced, and reflects potential complexity of the language. I think I'd still prefer to see a formatter attempt to preserve a

The Dart formatter sounds really advanced, and reflects potential complexity of the language. I think I'd still prefer to see a formatter attempt to preserve any formatting which is already 'good enough' to pass as an output threshold. Code isn't just a recipe for a computer to do something, it's a language for explaining to other programmers what that thing is and what's important to the structure of accomplishing it. The choice of where to place a break can matter for cognition and can be almost as important as the printed characters for organizing thoughts.

munificent 5y ago
> reflects potential complexity of the language. The language is fairly complex syntactically and that definitely adds some cost to formatting. But I think much of the complexity comes from two things: 1. A lot of idiomatic Dart uses function literals in a block-like way, as in: test(() { expect(1 + 2, 3); }); 2. But Dart doesn't actually having trailing block argument syntax like Smalltalk, Ruby, and Kotlin. So the formatter has to look at the closures passed to an argument list and decide which ones look better using block formatting, versus regular argument list formatting like: someFunction( () { expect(1 + 2, 3); }); Also, at the time I first wrote dartfmt, there was a lot of very nicely hand-formatted code in the wild that used different subtle layout choices to make different argument lists look nice. In order to persuade people to adopt the formatter at all, it had to be sophisticated enough to figure out many of those patterns and apply them automatically. It's not as good as a human (mainly because it doesn't have semantic context) but it had to be pretty close or people wouldn't have tried it. Now that it's well established, I think it would probably be possible to simplify how it formats while still making users happy. Possibly happier because the results would be a little easier to predict. > Code isn't just a recipe for a computer to do something, it's a language for explaining to other programmers what that thing is and what's important to the structure of accomplishing it. An automated formatter will never be as good as carefully crafted artisanal formatting. In particular, automated formatters don't know what stuff means. A good human might choose to line break a function call like so: setColor(red: 123, green: 54, blue: 26, alpha: 45); Because they know that "RGB" is a single coherent concept and alpha is less closely related. An automated formatter doesn't (and probably shouldn't) have that domain knowledge. But the value proposition of automated formatting is not just "how nice is the resulting code to read". You have to look at the total value proposition of completely yielding formatting to a tool versus allowing human control over it. When it's completely automated: 1. You can run it on generated code that contains absolutely no whitespace and still get nice output. 2. Humans can do large-scale refactorings, format, and get output that is consistent with the existing state of the codebase without having to understand any local style preferences. 3. Humans never have to spend time deciding how to format. Further, they don't even have to spend time deciding if they should format. 4. When reading a random codebase, it is likely to be formatted in a style you are used to even if you have zero communication with that team. This is particularly important in open source. 5. The code looks familiar to you wherever you encounter it: IDEs, plain text editors, code review tools, blog posts, StackOverflow answers. As opposed to letting everyone pick their own style and relying on users to apply their preferred style locally, it's just always in a familiar style. 6. Like any automation, the tool doesn't make mistakes. Even very careful humans hand-formatting make more mistakes than they realize. (I know because I've looked at their code). Those mistakes can be distracting for readers. 7. It gets people out of the mindset of being nitpicky about style. It encourages them to stay focused on the structure and naming of their code, which is what really matters. 8. It eliminates style arguments in code reviews. Those take time and, worse, cause disharmony, for next to no benefit. I think it's very worth excepting some small loss of overall formatting quality to get those in return.
CodesInChaos 5y ago
> The Dart formatter sounds really advanced, and reflects potential complexity of the language. I would not be surprised if a lisp formatter following the same philosophy as the dart formatter would be similarly complex, since the complexity comes from optimizing line length, not parsing.
- mbrock 5y ago
  Incidentally I spent yesterday implementing a Lisp formatter with the algorithm described by Jean-Philippe Bernardy in the simple and elegant paper "A Pretty But Not Greedy Printer." https://jyp.github.io/pdf/Prettiest.pdf https://jyp.github.io/pdf/Prettiest.pdf It's based on introducing choice between vertical and horizontal stacking. It avoids combinatorial explosion by pruning away strictly suboptimal choices. With just a few extra rules for Lisp forms, the results are quite good. I don't handle comments though, since I only need it for pretty printing values so far.
  - lakecresva 5y ago
    I also wrote a version of Bernardy's pretty printer, but I never did come up with a satisfactory way of formatting text together with code. The best looking solution of splitting on whitespace and making each word a group, either tacking it onto the current line or splitting onto a new line ends up being exponential even with pretty aggressive optimization. Everything else I tried looked bad.
mushyhammer 5y ago
> I think I'd still prefer to see a formatter attempt to preserve any formatting which is already 'good enough' to pass as an output threshold. That feels like Prettier sometimes. I think it leaves some objects on multiple lines or one line depending on how you leave them. But I’m not too sure.
rendall 5y ago
There is tension between having a single source of truth for source code, including an opinionated formatter; and allowing individual programmers expressive facility to format and structure code in a way that makes most sense to them. I've been thinking lately of a formatter that would resolve this tension. It would be a local, individual formatter, complementary to the global, opinionated, "Prettier" formatter. When the source code was committed to remote for review, the opinionated formatter would do its thing, making sure the code was formatted properly according to whatever the team agreed. But locally, the code would remain however the developer liked it.
- hprotagonist 5y ago
  a recipe for merge conflicts. i think maybe your only hope is to somehow “version the AST”, and let formatting be a style sheet or something. But i’m 1. talking out my butt and 2. sure i’m missing something.
  - rendall 5y ago
    > let formatting be a style sheet That's a good expression of the idea. If merge conflicts happen, we're doing it all wrong. Version control shouldn't even really be aware of this.
    - Cullinet 5y ago
      the most extreme validation of typographical precision is the banknote. Discuss?...
    - hprotagonist 5y ago
      tree-sitter and git: now kith!
  - fragmede 5y ago
    It's a decent idea! One problem though is all of the non-code elements, aka comments and how they intentionally align up with the code (mixed with spaces and tabs), so the ideal format is the one the original programmer wrote it in, and the second programmer using a different stylesheet can't edit comments and have them end up pretty for the first programmer. (The solution, obviously, is to not comment any code >_< )
ramraj07 5y ago
It might be true but as OP says in the article, the moment you have potential multiple ways to show the same piece of code, you’re going to surface engineers with each opinion on the code review. Getting an opinionated formatter is the best way to bring engineers back to do what they really need to be doing in code review, which is review the code not its formatting. I’ll never go back to python without black and Isort!
- fxtentacle 5y ago
  I feel like enforcing a specific text style is the wrong approach. In my opinion, different people have different formatting preferences and forcing someone to use the "wrong" one will lead to slower reading speed and the risk of overlooking errors. That's why I believe we should treat it like font or color choices. The IDE should display source code in the viewer's preferred style, so that each person sees what they expect. And then the actual source code formatting becomes irrelevant. Go already goes a good step into this direction by making a language AST tree part of their core libraries. And opening Go source code in JetBrain's GoLand will show you additional annotations, spacing, etc. based on the parsed source code tree (and not based on the source code's text).
  - awild 5y ago
    From experience I can tell that one can get used to other people's styles and just work with that oneself. Unifying among an enforced style and sticking to it really reduces the amount of unnecessary discussions. I genuinely feel that focusing a lot on the detriment of someone else's or an established code style is a sign of a lack of team work.
  - davemp 5y ago
    Having a strictly (formatter) enforced style is actually how you allow people the freedom to use their preferred style. Everyone can just set up a pre-commit hook to automatically format the code back into the official style, then everyone is free to put the codebase back into their preferred style. Otherwise, if developers reformatted code to their preferred style regularly, it would create massive diffs.
virtualwhys 5y ago
> The Dart formatter sounds really advanced, and reflects potential complexity of the language. You got that right -- check out this epic GitHub thread on optional semi-colons [1], and the author's own comment on the subject in an HN thread [2] [1] https://github.com/dart-lang/language/issues/69 https://github.com/dart-lang/language/issues/69 [2] https://news.ycombinator.com/item?id=22706645 https://news.ycombinator.com/item?id=22706645
rowanG077 5y ago
I'd really hate a formatter to attempt to preserve formatting if it's "close enough"(tm). Because what is "close enough"(tm) is hugely subjective, like formatting style itself. Formatter should just format to a common style. No funny business.
atoav 5y ago
I thought so as well. Until one day I just switched on black for python to see what it is like. I realized there was a tradeoff I never considered — the amount of time it would cost me to manually format only 10% better than the black formatter is not something I am willing to invest. And this is me talking about ideal situations where I calmy try to write beautiful code, when you consider that often you are not in the mood to spend a ton of time on formatting, because it distracts you from focusing onto the actual data flow, logic and so on a formatter as good as this is just beautiful. This is not something I would've said before I tried the thing btw.

munificent 5y ago

> reflects potential complexity of the language. The language is fairly complex syntactically and that definitely adds some cost to formatting. But I think much of the complexity comes from two things: 1. A lot of idiomatic Dart uses function literals in a block-like way, as in: test(() { expect(1 + 2, 3); }); 2. But Dart doesn't actually having trailing block argument syntax like Smalltalk, Ruby, and Kotlin. So the formatter has to look at the closures passed to an argument list and decide which ones look better using block formatting, versus regular argument list formatting like: someFunction( () { expect(1 + 2, 3); }); Also, at the time I first wrote dartfmt, there was a lot of very nicely hand-formatted code in the wild that used different subtle layout choices to make different argument lists look nice. In order to persuade people to adopt the formatter at all, it had to be sophisticated enough to figure out many of those patterns and apply them automatically. It's not as good as a human (mainly because it doesn't have semantic context) but it had to be pretty close or people wouldn't have tried it. Now that it's well established, I think it would probably be possible to simplify how it formats while still making users happy. Possibly happier because the results would be a little easier to predict. > Code isn't just a recipe for a computer to do something, it's a language for explaining to other programmers what that thing is and what's important to the structure of accomplishing it. An automated formatter will never be as good as carefully crafted artisanal formatting. In particular, automated formatters don't know what stuff means. A good human might choose to line break a function call like so: setColor(red: 123, green: 54, blue: 26, alpha: 45); Because they know that "RGB" is a single coherent concept and alpha is less closely related. An automated formatter doesn't (and probably shouldn't) have that domain knowledge. But the value proposition of automated formatting is not just "how nice is the resulting code to read". You have to look at the total value proposition of completely yielding formatting to a tool versus allowing human control over it. When it's completely automated: 1. You can run it on generated code that contains absolutely no whitespace and still get nice output. 2. Humans can do large-scale refactorings, format, and get output that is consistent with the existing state of the codebase without having to understand any local style preferences. 3. Humans never have to spend time deciding how to format. Further, they don't even have to spend time deciding if they should format. 4. When reading a random codebase, it is likely to be formatted in a style you are used to even if you have zero communication with that team. This is particularly important in open source. 5. The code looks familiar to you wherever you encounter it: IDEs, plain text editors, code review tools, blog posts, StackOverflow answers. As opposed to letting everyone pick their own style and relying on users to apply their preferred style locally, it's just always in a familiar style. 6. Like any automation, the tool doesn't make mistakes. Even very careful humans hand-formatting make more mistakes than they realize. (I know because I've looked at their code). Those mistakes can be distracting for readers. 7. It gets people out of the mindset of being nitpicky about style. It encourages them to stay focused on the structure and naming of their code, which is what really matters. 8. It eliminates style arguments in code reviews. Those take time and, worse, cause disharmony, for next to no benefit. I think it's very worth excepting some small loss of overall formatting quality to get those in return.

CodesInChaos 5y ago

> The Dart formatter sounds really advanced, and reflects potential complexity of the language. I would not be surprised if a lisp formatter following the same philosophy as the dart formatter would be similarly complex, since the complexity comes from optimizing line length, not parsing.

mbrock 5y ago
Incidentally I spent yesterday implementing a Lisp formatter with the algorithm described by Jean-Philippe Bernardy in the simple and elegant paper "A Pretty But Not Greedy Printer." https://jyp.github.io/pdf/Prettiest.pdf https://jyp.github.io/pdf/Prettiest.pdf It's based on introducing choice between vertical and horizontal stacking. It avoids combinatorial explosion by pruning away strictly suboptimal choices. With just a few extra rules for Lisp forms, the results are quite good. I don't handle comments though, since I only need it for pretty printing values so far.
- lakecresva 5y ago
  I also wrote a version of Bernardy's pretty printer, but I never did come up with a satisfactory way of formatting text together with code. The best looking solution of splitting on whitespace and making each word a group, either tacking it onto the current line or splitting onto a new line ends up being exponential even with pretty aggressive optimization. Everything else I tried looked bad.

mushyhammer 5y ago

> I think I'd still prefer to see a formatter attempt to preserve any formatting which is already 'good enough' to pass as an output threshold. That feels like Prettier sometimes. I think it leaves some objects on multiple lines or one line depending on how you leave them. But I’m not too sure.

rendall 5y ago

There is tension between having a single source of truth for source code, including an opinionated formatter; and allowing individual programmers expressive facility to format and structure code in a way that makes most sense to them. I've been thinking lately of a formatter that would resolve this tension. It would be a local, individual formatter, complementary to the global, opinionated, "Prettier" formatter. When the source code was committed to remote for review, the opinionated formatter would do its thing, making sure the code was formatted properly according to whatever the team agreed. But locally, the code would remain however the developer liked it.

hprotagonist 5y ago
a recipe for merge conflicts. i think maybe your only hope is to somehow “version the AST”, and let formatting be a style sheet or something. But i’m 1. talking out my butt and 2. sure i’m missing something.
- rendall 5y ago
  > let formatting be a style sheet That's a good expression of the idea. If merge conflicts happen, we're doing it all wrong. Version control shouldn't even really be aware of this.
  - Cullinet 5y ago
    the most extreme validation of typographical precision is the banknote. Discuss?...
  - hprotagonist 5y ago
    tree-sitter and git: now kith!
- fragmede 5y ago
  It's a decent idea! One problem though is all of the non-code elements, aka comments and how they intentionally align up with the code (mixed with spaces and tabs), so the ideal format is the one the original programmer wrote it in, and the second programmer using a different stylesheet can't edit comments and have them end up pretty for the first programmer. (The solution, obviously, is to not comment any code >_< )

ramraj07 5y ago

It might be true but as OP says in the article, the moment you have potential multiple ways to show the same piece of code, you’re going to surface engineers with each opinion on the code review. Getting an opinionated formatter is the best way to bring engineers back to do what they really need to be doing in code review, which is review the code not its formatting. I’ll never go back to python without black and Isort!

fxtentacle 5y ago
I feel like enforcing a specific text style is the wrong approach. In my opinion, different people have different formatting preferences and forcing someone to use the "wrong" one will lead to slower reading speed and the risk of overlooking errors. That's why I believe we should treat it like font or color choices. The IDE should display source code in the viewer's preferred style, so that each person sees what they expect. And then the actual source code formatting becomes irrelevant. Go already goes a good step into this direction by making a language AST tree part of their core libraries. And opening Go source code in JetBrain's GoLand will show you additional annotations, spacing, etc. based on the parsed source code tree (and not based on the source code's text).
- awild 5y ago
  From experience I can tell that one can get used to other people's styles and just work with that oneself. Unifying among an enforced style and sticking to it really reduces the amount of unnecessary discussions. I genuinely feel that focusing a lot on the detriment of someone else's or an established code style is a sign of a lack of team work.
- davemp 5y ago
  Having a strictly (formatter) enforced style is actually how you allow people the freedom to use their preferred style. Everyone can just set up a pre-commit hook to automatically format the code back into the official style, then everyone is free to put the codebase back into their preferred style. Otherwise, if developers reformatted code to their preferred style regularly, it would create massive diffs.

virtualwhys 5y ago

> The Dart formatter sounds really advanced, and reflects potential complexity of the language. You got that right -- check out this epic GitHub thread on optional semi-colons [1], and the author's own comment on the subject in an HN thread [2] [1] https://github.com/dart-lang/language/issues/69 https://github.com/dart-lang/language/issues/69 [2] https://news.ycombinator.com/item?id=22706645 https://news.ycombinator.com/item?id=22706645

rowanG077 5y ago

I'd really hate a formatter to attempt to preserve formatting if it's "close enough"(tm). Because what is "close enough"(tm) is hugely subjective, like formatting style itself. Formatter should just format to a common style. No funny business.

atoav 5y ago

I thought so as well. Until one day I just switched on black for python to see what it is like. I realized there was a tradeoff I never considered — the amount of time it would cost me to manually format only 10% better than the black formatter is not something I am willing to invest. And this is me talking about ideal situations where I calmy try to write beautiful code, when you consider that often you are not in the mood to spend a ton of time on formatting, because it distracts you from focusing onto the actual data flow, logic and so on a formatter as good as this is just beautiful. This is not something I would've said before I tried the thing btw.