In my brief experiments with Flutter, I must admit I didn't enjoy the experience of using the autoformatting. Not knocking the author of the tool at all, I can definitely see how absurdly hard it is to create something that does what it is trying to do. And I'm not against autoformatting in general either. I think gofmt works much better, and that's in large part because it tries to do less.
With dart, I felt that very often, when time I saved a file after editing (which activated the formatter), the code would jump around a lot, even for very small edits sometimes. I actually found myself saving less often, as I found the sudden reorganizing kind of jarring and disorienting.
Most of this, I felt like came from this wish of making the formatter keep lines inside a given width. While that's a goal I appreciate, I've come to think is one of those things that's better done manually. The same goes for the use of whitespace in general, other than trivial stuff like consistent indentation. There's actual, important meaning that can be conveyed in how you arrange things which I think is more important than having it always be exactly mathematically consistent.
It's one of the reasons I still prefer ESLint over Prettier in JS land, also, even for stylistic rules. The fact that Prettier always rewrites the entire file from scratch with the parsed AST often ends up mangling some deliberate way that I'd arrange the code.
One of the lessons I took from the formatters (Python, Go, Rust) is that enforcing the same style ends all of the drama - indeed, all of the thinking - about how to format code. I like that.
I run my formatters manually, so I can’t comment on the jumps in code. That does seem jarring.
Again, I don't entirely disagree. Some choices are entirely stylistic: single vs double quotes for strings. Tabs vs spaces. Indentation width. Trailing commas. Those (and others) encode literally 0 meaning, and any time discussing those is time wasted, so they should be auto formatted away.
But some things are not like that. Two statements being right against each other, or having an empty line between them, encodes information.
In a big function call with many arguments, where do you add line breaks between arguments? That can convey information as well. As the posted link says, those are some of the most difficult scenarios for a formatter to try to deal with, and my point is that I think it's not worth the effort.
With dart, I felt that very often, when time I saved a file after editing (which activated the formatter), the code would jump around a lot, even for very small edits sometimes. I actually found myself saving less often, as I found the sudden reorganizing kind of jarring and disorienting.
Most of this, I felt like came from this wish of making the formatter keep lines inside a given width. While that's a goal I appreciate, I've come to think is one of those things that's better done manually. The same goes for the use of whitespace in general, other than trivial stuff like consistent indentation. There's actual, important meaning that can be conveyed in how you arrange things which I think is more important than having it always be exactly mathematically consistent.
It's one of the reasons I still prefer ESLint over Prettier in JS land, also, even for stylistic rules. The fact that Prettier always rewrites the entire file from scratch with the parsed AST often ends up mangling some deliberate way that I'd arrange the code.