Open dcharkes opened 3 weeks ago
Consider flowing short values in list/set/map literals, instead of putting one per line. Maybe set a limit of "short" meaning <= 8 characters or something. Then you can still fit at least 7 on a line. Or maybe do that for lists where the average element length is "short", allowing a few longer elements too.
One element per line is prohibitively annoying and unreadable for larger lists of numbers or other short elements. Using comments to control the formatter is a mis-feature, but I'll use it if it's all I have. Or I'll encode my numbers as a string and use String.codeUnitAt
for lookup. Expressing a code page as 128 or 256 lines of byte values just won't fly.
(I won't try to convince everyone that
final matcher = equals([
72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 10, 0, 42, 88,
150, 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 10, 0, 255
]);
is the optimal alignment for a table of integers. Even though it clearly is, just ask Excel.)
The new tall style prefers making int lists span many lines even if they'd fit on one line:
->
I don't mind that much, but maybe we can detect cases where all elements in a list fit on one line and not make them tall?
Source file: https://github.com/dart-lang/native/blob/main/pkgs/ffi/test/utf8_test.dart