dart-lang / dart_style

An opinionated formatter/linter for Dart code
https://pub.dev/packages/dart_style
BSD 3-Clause "New" or "Revised" License
645 stars 118 forks source link

[tall style] int lists spanning many lines #1540

Open dcharkes opened 3 weeks ago

dcharkes commented 3 weeks ago

The new tall style prefers making int lists span many lines even if they'd fit on one line:

  test('toUtf8 ASCII', () {
    final start = 'Hello World!\n';
    final converted = start.toNativeUtf8().cast<Uint8>();
    final end = converted.asTypedList(start.length + 1);
    final matcher = equals(
      [72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 10, 0],
    );
    expect(end, matcher);
    calloc.free(converted);
  });

->

  test('toUtf8 ASCII', () {
    final start = 'Hello World!\n';
    final converted = start.toNativeUtf8().cast<Uint8>();
    final end = converted.asTypedList(start.length + 1);
    final matcher = equals([
      72,
      101,
      108,
      108,
      111,
      32,
      87,
      111,
      114,
      108,
      100,
      33,
      10,
      0,
    ]);
    expect(end, matcher);
    calloc.free(converted);
  });

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

lrhn commented 2 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.)