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