Use "@dart=" comment when determining which style rules to apply. (#1766)

Use "@dart=" comment when determining which style rules to apply.

The formatter correctly used those comments to switch between the old
short and new tall style, but ignored them for language versioned style
rule changes after 3.7. Now the language version of the file is
consistently respected for all style rules.

In the process of fixing this, I made two other clean-ups:

* Introduce a FormattingStyle class separate from DartFormatter. The
  latter had dual use as both the public API used to configure
  formatting and the internal object passed around by the formatter to
  access that configuration. That was annoying because it meant I
  couldn't hang handy utility methods that the implementation wants off
  that class because it's public. And it meant that I couldn't change
  what state it stored (like the language version from the "@dart"
  comment) without it being a breaking API change.

  Now there is a separate internal class that wraps the DartFormatter
  that can contain that logic. By consistently passing that around and
  not the DartFormatter, it ensures that code can't accidentally forget
  to use the language version in the "@dart" comment.

* Pick a consistent naming convention for version numbers in
  identifiers. When we shipped Dart 3.8, a bunch of style rules changed.
  I needed a way to refer to the older style and couldn't come up with
  anything better than "3.7". But you can't have a dot in identifier,
  so I did "37". With Dart 3.10 on the horizon, that doesn't make sense:
  "310" is confusing and ambiguous. I considered "3_7", but that
  violates the lint for type names which shouldn't contain "_". Went
  with "3Dot7" instead which I don't love but seems to work.

Fix #1762.
18 files changed
tree: 63ec516d7f1095bc4472b67abfc0effee191cb76
  1. .github/
  2. benchmark/
  3. bin/
  4. dist/
  5. example/
  6. lib/
  7. test/
  8. tool/
  9. .gitignore
  10. analysis_options.yaml
  11. AUTHORS
  12. CHANGELOG.md
  13. LICENSE
  14. pubspec.yaml
  15. README.md
README.md

The dart_style package defines an opinionated, minimally configurable automated formatter for Dart code.

It replaces the whitespace in your program with what it deems to be the best formatting for it. It also makes minor changes around non-semantic punctuation like trailing commas and brackets in parameter lists.

The resulting code should follow the Dart style guide and look nice to most human readers, most of the time.

The formatter handles indentation, inline whitespace, and (by far the most difficult) intelligent line wrapping. It has no problems with nested collections, function expressions, long argument lists, or otherwise tricky code.

The formatter turns code like this:

process = await Process.start(path.join(p.pubCacheBinPath,Platform.isWindows
?'${command.first}.bat':command.first,),[...command.sublist(1),'web:0',
// Allow for binding to a random available port.
],workingDirectory:workingDir,environment:{'PUB_CACHE':p.pubCachePath,'PATH':
path.dirname(Platform.resolvedExecutable)+(Platform.isWindows?';':':')+
Platform.environment['PATH']!,},);

into:

process = await Process.start(
  path.join(
    p.pubCacheBinPath,
    Platform.isWindows ? '${command.first}.bat' : command.first,
  ),
  [
    ...command.sublist(1), 'web:0',
    // Allow for binding to a random available port.
  ],
  workingDirectory: workingDir,
  environment: {
    'PUB_CACHE': p.pubCachePath,
    'PATH':
        path.dirname(Platform.resolvedExecutable) +
        (Platform.isWindows ? ';' : ':') +
        Platform.environment['PATH']!,
  },
);

The formatter will never break your code—you can safely invoke it automatically from build and presubmit scripts.

Formatting files

The formatter is part of the unified dart developer tool included in the Dart SDK, so most users run it directly from there using dart format.

IDEs and editors that support Dart usually provide easy ways to run the formatter. For example, in Visual Studio Code, formatting Dart code will use the dart_style formatter by default. Most users have it set to reformat every time they save a file.

Here's a simple example of using the formatter on the command line:

$ dart format my_file.dart

This command formats the my_file.dart file and writes the result back to the same file.

The dart format command takes a list of paths, which can point to directories or files. If the path is a directory, it processes every .dart file in that directory and all of its subdirectories.

By default, dart format formats each file and writes the result back to the same files. If you pass --output show, it prints the formatted code to stdout and doesn't modify the files.

Validating formatting

If you want to use the formatter in something like a presubmit script or commit hook, you can pass flags to omit writing formatting changes to disk and to update the exit code to indicate success/failure:

$ dart format --output=none --set-exit-if-changed .

Using the formatter as a library

The `dart_style package exposes a simple library API for formatting code. Basic usage looks like this:

import 'package:dart_style/dart_style.dart';

main() {
  final formatter = DartFormatter(
    languageVersion: DartFormatter.latestLanguageVersion,
  );

  try {
    print(formatter.format("""
    library an_entire_compilation_unit;

    class SomeClass {}
    """));

    print(formatter.formatStatement("aSingle(statement);"));
  } on FormatterException catch (ex) {
    print(ex);
  }
}

Other resources

  • Before sending an email, see if you are asking a frequently asked question.

  • Before filing a bug, or if you want to understand how work on the formatter is managed, see how we track issues.