Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tall style] int lists spanning many lines #1540

Open
dcharkes opened this issue Aug 17, 2024 · 1 comment
Open

[tall style] int lists spanning many lines #1540

dcharkes opened this issue Aug 17, 2024 · 1 comment

Comments

@dcharkes
Copy link

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
Copy link
Member

lrhn commented Aug 27, 2024

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants