The Evolution of Dart Format: Inside the New Tall Style and Formatting Architecture

Consistent code formatting is essential for healthy, readable software projects. For years, Dart developers took pride in dart format (formerly dartfmt), the zero-configuration autoformatter built straight into the Dart SDK.

However, as Dart added records, pattern matching, class modifiers, and primary constructors, the legacy formatting algorithm—designed over a decade ago—began showing its age. To solve nested readability challenges and ambiguous trailing comma rules, the Dart team engineered a ground-up overhaul of the formatter: the “Tall Style” formatting engine.

In this article, we break down what changed, why it matters, and how to harness the modern formatting toolchain in your CI/CD workflows.

1. Why Did the Old Formatter Need an Overhaul?

The original Dart formatting engine relied on a page-width constraint (default 80 columns) paired with a backtracking search algorithm. While effective for simple statements, it suffered from notable limitations:

1. The “Short Style” Trailing Comma Hack: In Flutter code, developers had to manually add a trailing comma , just to force the formatter to split arguments across multiple lines. Forgetting a single comma could result in unreadable 80-character horizontal chains.
2. Poor Support for Modern Language Features: Record patterns, destructuring expressions, and complex switch expressions often wrapped awkwardly across lines.
3. Cascading Indentation Creep: Highly nested structures (such as deeply nested widget trees or chained collection literals) quickly consumed horizontal screen space.

2. Introducing the “Tall Style” Engine

The modern dart format engine adopts an improved line-breaking strategy known colloquially as tall style.

Key Behavioral Enhancements

• Smarter Vertical Splitting: The formatter analyzes the semantic hierarchy of function parameters and widget constructors. Even without manual trailing commas, it cleanly wraps argument lists vertically when they contain complex expressions.
• Natural Record and Pattern Wrapping: Records with positional and named fields break cleanly:

// Modern tall formatting of complex records and patterns
final (
  statusCode,
  headers: {
    'content-type': mimeType,
    'authorization': authToken,
  },
  body,
) = await fetchApiResponse();

• Consistent Collection Literal Layouts: Lists, sets, and maps with nested objects prioritize visual alignment over cramming elements onto the same line:

final Map<String, dynamic> payload = {
  'session': {
    'id': sessionId,
    'issuedAt': DateTime.now().toIso8601String(),
    'capabilities': [
      'read:profile',
      'write:documents',
      'admin:settings',
    ],
  },
};

3. Configurable Page Width and CLI Options

While 80 characters remains the recommended default for maximum split-screen readability, teams working on widescreen monitors or enterprise codebases often prefer wider line budgets.

dart format provides full command-line flexibility:

# Format the entire project with the default 80-column line length
dart format .

# Format with an expanded 100 or 120-column line length
dart format -l 100 .

# Check formatting in CI without writing changes (fails with non-zero exit code if unformatted)
dart format --output=none --set-exit-if-changed .

You can also specify line length inside your analysis_options.yaml:

formatter:
  page_width: 100

4. Integrating dart format in Automated CI/CD Pipelines

To prevent formatting discrepancies from cluttering pull request diffs, automated formatting gates should run on every commit.

Here is an optimized GitHub Actions workflow step for Dart & Flutter:

name: Quality Gate

on: [push, pull_request]

jobs:
  code-formatting:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Dart SDK
        uses: dart-lang/setup-dart@v1
        with:
          sdk: stable

      - name: Verify Formatting
        run: dart format --output=none --set-exit-if-changed .

      - name: Analyze Code
        run: dart analyze --fatal-infos

If a developer forgets to format before pushing, the CI pipeline fails immediately with the exact filenames requiring formatting.

5. Best Practices for Developers and Teams

1. Turn on Format on Save in your IDE: In VS Code (editor.formatOnSave: true) and Android Studio (Actions on Save -> Reformat code), ensure formatting executes transparently on every keystroke save.
2. Embrace Automatic Breaking: Resist the urge to manually adjust indentation or add arbitrary line breaks. Let the tool manage aesthetics so the team can focus on architecture and correctness.
3. Run Pre-Commit Hooks: Utilize tools like husky or git pre-commit hooks with dart format --fix to catch unformatted files before they hit remote branches.

The tall style evolution marks a major milestone in Dart’s developer experience, ensuring codebases remain elegant, readable, and free from bike-shedding formatting disputes.