You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are three ways an argument list can be formatted:
```dart
// 1. All inline:
function(argument, another);
// 2. Block formatted:
function(argument, [
element,
element,
]);
// 3. Tall style:
function(
argument,
another,
);
```
One of the trickiest parts of the formatter is deciding the heuristics to choose between 2 and 3.
Prior to this PR, there is a fairly subtle rule: Arguments before the block argument can be named or not, the block argument can be named or not, and the argument after the block argument can be named or not, but only one of those three sections can have a named argument.
The intent of that rule is to allow named block arguments and named non-block arguments, while avoiding multiple argument names on the same line when block formatted. Also, it allows an argument list containing only a named argument to be block formatted:
```dart
function(name: [
element,
]);
```
From looking at how contributors to Flutter have hand-formatted their code, it doesn't look like this level of complexity is well motivated. And allowing a single named argument to be block formatted but not if there are other named arguments means that adding a second named argument to a function can cause the entire argument list to be reformatted and indented differently. That can be a lot of churn if the block argument is itself a large nested widget tree.
This PR tweaks that rule to something simpler:
1. The block argument must be positional.
2. Other non-block arguments have no restrictions on whether they can be named or not.
This reduces diff churn and means that widget trees (which almost always use named arguments) have a more consistent (but taller) style across the entire tree.
From talking to Michael Goderbauer, this seems like a reasonable trade-off to me.
0 commit comments