Shorter code creates more lines

[passsy]

Hey Bob,

Some feedback on the new proposed style for Dart 3.7. I tested it with my spot package and found this interesting case I can't explain. It looks like a bug to me.

Before

unformatted, does not fit within 80 characters

void main() {
  testWidgets('sometest', (tester) async {
    final appBar = spot<AppBar>();
    
    appBar.spotIcon(Icons.settings, parents: [spot<IconButton>()]).doesNotExist();

    appBar.spotIcon(Icons.home, parents: [spot<IconButton>()]).existsExactlyNTimes(2);
  });
}

Actual

// Formatted with Dart 3.5
void main() {
  testWidgets('sometest', (tester) async {
    final appBar = spot<AppBar>();

    appBar
        .spotIcon(Icons.settings, parents: [spot<IconButton>()]).doesNotExist();

    appBar.spotIcon(Icons.home,
        parents: [spot<IconButton>()]).existsExactlyNTimes(2);
  });
}

// Formatted with Dart 3.7 (--git-ref=flutter-style-experiment)
void main() {
  testWidgets('sometest', (tester) async {
    final appBar = spot<AppBar>();

    appBar.spotIcon(
      Icons.settings,
      parents: [spot<IconButton>()],
    ).doesNotExist();

    appBar
        .spotIcon(Icons.home, parents: [spot<IconButton>()])
        .existsExactlyNTimes(2);
  });
}

What's unclear is why the first appBar.spotIcon line creates 4 LOC, whereas the second only requires 3.

It is possible to format the first line, like the second, without any problem. Why do they behave differently?

Expected

void main() {
  testWidgets('sometest', (tester) async {
    final appBar = spot<AppBar>();

    appBar
        .spotIcon(Icons.settings, parents: [spot<IconButton>()])
        .doesNotExist();

    appBar
        .spotIcon(Icons.home, parents: [spot<IconButton>()])
        .existsExactlyNTimes(2);
  });
}

[munificent]

It is possible to format the first line, like the second, without any problem. Why do they behave differently?

In general, neither the old nor the new style have rules that try to minimize the number of lines. They try to minimize the cost but a single point of cost may mean one or more newlines getting inserted depending on how each formatting rule behaves.

In cases like your examples, there are a number of valid ways the code could be line split to fit in the page width and determining which to prefer over others is a pretty delicate game of heuristics.

I agree that your expected output looks nicer than the actual output in these examples. I'm less sure that tweaking the rules to yield that wouldn't end up make even more other examples look worse. We might be able to improve this, but I'll have to do some experimentation and try it out on a corpus to see if I can find anything that seems like an overall improvement. In general, deciding when to split as . versus inside argument lists tends to be one of the most challenging parts of the style rules.

[passsy]

Another example that leaves me puzzled where the new tall style adds an additional new line.

  var robots = input.split('\n').map((line) {
-    final matches =
-        RegExp(r'p=(-?\d+),(-?\d+) v=(-?\d+),(-?\d+)').allMatches(line);
+    final matches = RegExp(r'p=(-?\d+),(-?\d+) v=(-?\d+),(-?\d+)').allMatches(
+      line,
+    );
    final px = matches.first.group(1)!;
    final py = matches.first.group(2)!;
    final vx = matches.first.group(3)!;
    final vy = matches.first.group(4)!;
    assert(int.parse(px) < gridWidth);
    assert(int.parse(py) < gridHeight);
    return Robot(
      velocity: (dx: int.parse(vx), dy: int.parse(vy)),
      position: (x: int.parse(px), y: int.parse(py)),
    );
  }).toList();