Request: more sensible formatting for lists that require custom formatting

[alexobviously]

I originally submitted this as a dart-code issue but someone correctly pointed out that this is actually the correct place for it.

Is your feature request related to a problem? Please describe.
Take for example this list, which needs to be viewed in a square because that's what it represents:

static const List<int> RAYS = [
     17,  0,  0,  0,  0,  0,  0, 16,  0,  0,  0,  0,  0,  0, 15, 0,
      0, 17,  0,  0,  0,  0,  0, 16,  0,  0,  0,  0,  0, 15,  0, 0,
      0,  0, 17,  0,  0,  0,  0, 16,  0,  0,  0,  0, 15,  0,  0, 0,
      0,  0,  0, 17,  0,  0,  0, 16,  0,  0,  0, 15,  0,  0,  0, 0,
      0,  0,  0,  0, 17,  0,  0, 16,  0,  0, 15,  0,  0,  0,  0, 0,
      0,  0,  0,  0,  0, 17,  0, 16,  0, 15,  0,  0,  0,  0,  0, 0,
      0,  0,  0,  0,  0,  0, 17, 16, 15,  0,  0,  0,  0,  0,  0, 0,
      1,  1,  1,  1,  1,  1,  1,  0, -1, -1,  -1,-1, -1, -1, -1, 0,
      0,  0,  0,  0,  0,  0,-15,-16,-17,  0,  0,  0,  0,  0,  0, 0,
      0,  0,  0,  0,  0,-15,  0,-16,  0,-17,  0,  0,  0,  0,  0, 0,
      0,  0,  0,  0,-15,  0,  0,-16,  0,  0,-17,  0,  0,  0,  0, 0,
      0,  0,  0,-15,  0,  0,  0,-16,  0,  0,  0,-17,  0,  0,  0, 0,
      0,  0,-15,  0,  0,  0,  0,-16,  0,  0,  0,  0,-17,  0,  0, 0,
      0,-15,  0,  0,  0,  0,  0,-16,  0,  0,  0,  0,  0,-17,  0, 0,
    -15,  0,  0,  0,  0,  0,  0,-16,  0,  0,  0,  0,  0,  0,-17
  ];

When I save the file in vscode, the formatter changes it to:

static const List<int> RAYS = [
    17,
    0,
    0,
    0,
    0,
    0,
    0,
    16,
    0,
    0,
    0,
    0,
    0,
    0,
    15,
    0,
    0,

and so on.

Describe the solution you'd like
Maybe someone has a better solution than this, but what I think would work is that if the formatter detects a list that has already been broken into rows, if any of them has more than 1 item then it understands this was done deliberately and doesn't reformat the list.

Describe alternatives you've considered
The only solution I've found so far is to save these lists in some constants.dart, disable the dart formatter while saving it and then turn it back on. Maybe there's another way that I can't find in the settings.

Also related, I have another constant like this:

static const DEFAULT_BRACKET = [[0]];

that gets broken into this:

static const DEFAULT_BRACKET = [
    [0]
];

and this is also not desirable.

[munificent]

If you place at least one line comment inside the list literal, it will preserve your newlines. It doesn't keep the extra spaces before the elements that you're using to line up things. This is a challenging problem. Users rely on the formatter heavily to clean up unformatted code, and it's really hard to tell which formatting is deliberate (like yours here) and which isn't.

[benthillerkus]

I have this collection literal that represents a sequence of pulses to be sent via infrared:

const [4580,4470, 630,520, 630,520, 580,1670, 630,520, 580,1670, 630,520, 580,1670, 630,520, 630,1620, 630,520, 580,570, 580,520, 630,1670, 580,520, 630,1670, 580,520, 680,1620, 580,1670, 630,520, 580,520, 630,520, 630,520, 580,570, 580,520, 630,520, 580,570, 580,570, 580,1670, 580,570, 580,1670, 580,570, 580,1670, 580];

After formatting, every single item is in its own line, making the entire file pretty much unreadable, because there is one chunky boy that just looks like this:

Please let users mark an opt-out region via comments, similar to how users can deactivate the linter for a line:

// ignore: camel_case_types

[munificent]

If you place at least one line comment inside the list literal, it will preserve your newlines.

[benthillerkus]

If you place at least one line comment inside the list literal, it will preserve your newlines.

Unfortunately, it will still break when the max line length is reached. Which is fair, I guess, but not really useful in my case. Being able to opt out a region from formatting would still be the best way of handling it.

[munificent]

Being able to opt out a region from formatting would still be the best way of handling it.

There is a FAQ entry for that too. Being able to opt out of formatting for some regions has some positive value, but it comes with some trade-offs in terms of the overall user experience. I still lean towards it being a net negative to allow them, because then it will lead to users arguing about when and where to use them.

The whole point of dart format is to get users out of the business of worrying about how their code is formatted. The formatter won't ever do a perfect job, but it can hopefully do a tolerably good enough one that you can unload that responsibility entirely from your head.

[benthillerkus]

With all respect, users will always argue.
Right now, I “fixed” the problem by setting the max line length in my IDE to -1, so that dart format will not break my line. But obviously this is terrible, because now the file will format differently on different machines—potentially ruining version control history, if users are formatting their code.

By not being able to just opt out of a region, I can really only either opt out of dart format entirely and format manually, or I can accept the flaws, but then have to live with some files being a horrible mess to work with. Either way, I end up having to worry about formatting.

I don't understand why the philosophies behind the formatter and the linter are so different here, aren't both official dart-lang projects?

[munificent]

I don't understand why the philosophies behind the formatter and the linter are so different here, aren't both official dart-lang projects?

Yes, but they have some different constraints on them as well as a different history of usage. Linter rules are relatively independent from each other, so it's fairly low cost to support a variety of them and allow users to pick and choose. This isn't the case with the formatter where formatting options interact with subtle complex ways and testing all of the combinations of them gets combinatorially difficult.

We do have a recommended set of lints now, and that set is deliberately non-configurable. We expect all internal Dart users to follow it. Like with the formatter, we do that to avoid low-value but time consuming arguments about which lints should and should not be enabled.

[Reprevise]

I'm still very on the side of allowing disabling the formatter on certain regions of code. For anyone who has ever worked with ColorFilter.matrix() in Flutter, you know the formatter isn't your friend here. Thankfully I found out that you can put a // comment at the end of the trailing comma to preserve the line breaks, however when I want to align double values, the formatter trims the leading whitespace which is understandable, though it makes the list harder to read. The result that I want is:

const ColorFilter _kGreyscaleFilter = ColorFilter.matrix(<double>[
  0.2126, 0.7152, 0.0722, 0, 0,
  0.2126, 0.7152, 0.0722, 0, 0,
  0.2126, 0.7152, 0.0722, 0, 0,
  0,      0,      0,      1, 0,
]);

Now this can mostly be achieved with adding a single comment to the end of the trailing comma (which I'm really not a fan of, but at least the list is broken up nicely I guess), however you'll notice we lose the whitespace on the last row:

const ColorFilter _kGreyscaleFilter = ColorFilter.matrix(<double>[
  0.2126, 0.7152, 0.0722, 0, 0, //
  0.2126, 0.7152, 0.0722, 0, 0,
  0.2126, 0.7152, 0.0722, 0, 0,
  0, 0, 0, 1, 0,
]);

There are two ways in which this can be solved:

1. Allow disabling the formatter for certain regions of code
2. Have the formatter format lists like I showed in the first example (formatter would need to preserve line breaks automatically), which would be opinionated but the formatter is supposed to be opinioned really

[munificent]

Allow disabling the formatter for certain regions of code

I'm leaning towards supporting this too. I am (very) busy working on #1253 now, but after that (assuming I still have any bandwidth left), I intend to investigate support for opting regions out from formatting.

[munificent]

I didn't realize this was a duplicate of the (ancient and closed) #361. I'm going to resurrect that and merge this one with it.