Come up with a better way of communicating upcoming changes to the Dart formatter

[azimuthdeveloper]

From the implementation of #1253, and the resulting fallout (#1652 off the top of my head), it's probably fair to say that not enough active Flutter developers' were made aware of the upcoming changes to the Dart formatter.

I know that a lot of effort was expended to get the word out, but it seems it wasn't enough, or the avenues pursued did not have the impact or coverage that was expected.

The changes were announced:

• On Medium in an article half-way down about the formatter (https://medium.com/dartlang/announcing-dart-3-7-bf864a1b195c)
• The GitHub issue here
• On Google Groups (apparently, I can't access it): https://groups.google.com/a/google.com/g/dart-announce/c/VPKc25xDZ_I/m/N35x7UuKAAAJ

Unfortunately, none of these places are areas where developers frequent. I don't cruise Medium, GH or a google group I don't have access to looking for things that might affect me.

A lot of effort was given to try to reach people, but given how much discussion and pushback this has elicited, it seems safe to say that the communication strategy hasn't worked and might need some attention. I know that Android Studio tells me that Flutter supports hot-reload when I open it for the first time, and I know it prompts me to fill out the quarterly surveys, so maybe that could be somewhere that could be used to notify of big upcoming changes like this?

[tomgilder]

On top of better communication, one thing I've learned is that it's very difficult to evaluate formatting changes without trying it on your own code.

When I read the original proposal, I thought it sounded like an excellent idea (admittedly I did somewhat skim through it).

Had I run the formatter on almost any of my code, I would have voted against it.

And apparently it wasn't just me who read the proposal but didn't understand what the end results would be.

I appreciate there was a prototype implementation, but apparently I didn't notice it (or wasn't motivated enough to try it). Had there been a web app (such as a version of DartPad) where I could paste some code in, I think I would have tried it, and provided useful feedback.

[rrousselGit]

I don't think it's a mistake on their part. They did what they could.
The main issue is IMO that the proposal looks good on paper, but isn't when you play with it. And very few people tried out the dev version.

I'm one of the few who did try it out early and have ben pretty vocal about the issue (#1253 (comment) and many new issues). But even then, I understand that from their PoV at that time, I was one person complaining against a sea of upvotes for the proposal.

It's hard to prevent such a situation. What matters is what they'll do based on the recent feedback.
Will the formatting be tweaked to be better looking?
Will they add a configuration flag?
Will things just stay as they are?

[timnew]

I feel the name of "tall style" and the #1253 issue description is very misleading.

In the issue they called it "tall", and the examples in the issues look mostly reasonable. There are a few examples I might say Meh, but I can live with it.

What really being complained in #1652 is that the new format isn't really "tall", instead it makes the original tall code less tall by removing trailing comma and squeezing things into the same line.

Given the whole issue is talking about making things "tall", nothing about make things more compact or concise. And for some reason, this trailing comma removing behaviour was completely missed out from all the examples. So I have to say, to a certain degree, this comma removing behaviour should be considered as being smuggled into the codebase, and does not aligned on what people really upvoted for.

I can't tell whether it is intentionally being misleading or it is just a miscommunication. But personally I cannot understand why it is there (as it is opposite than "tall"), and I don't understand why it is not being clearly explained (as it is clearly an unexpected behaviour and would surprise people if it has a strong reason to be there).

And last, this is a really really big breaking change, and it is clearly a wrong way to deliver such change in this manner. As it impacts on every single code file you have, cause unfixable lint error, and has no way to opts out! Even an API upgrade will have some kind of deprecation warning for at least one version. And such a big change just shipped with a hard switch. Flutter just bumped a minor version instead of major version.

It caught people in surprise in every aspects, and enforced people to accept it. No doubt why people feel frustrated about it.

[mrcsh]

The new formatter has made my code much, much less readable. It introduces 2x-3x more horizontal indents and adds many newlines which visually dissociates the code from the named parameters. I use expression syntax for lambdas as much as I possibly can because I think they are easier to read and are more concise, but now they are an absolute mess.

things like

 buildWhen:
     (final previous, final current) =>
         previous.idleTimeout != current.idleTimeout ||
         previous.isBusy != current.isBusy,

used to look like

 buildWhen: (final previous, final current) =>
   previous.idleTimeout != current.idleTimeout ||
   previous.isBusy != current.isBusy,

When code is already highly indented the extra 4 + 4 indents cause even more wrapping. The changes have made all but the most expression lambda's completely unusable.

Switching everything back to block syntax is more readable than the newly formatted expression syntax and it makes me very sad.

I would have much preferred an opt-in parameter to try the new formatting out before trashing my code base.

This is a huge regression in my (probably no so humble) opinion, and will cause wasted hours trying to workaround this "improvement".