| commit | 42b9bd428e37ae166080fa837ce45c178f3391e9 | [log] [tgz] |
|---|---|---|
| author | Bob Nystrom <rnystrom@google.com> | Tue Feb 06 15:41:52 2024 -0800 |
| committer | GitHub <noreply@github.com> | Tue Feb 06 15:41:52 2024 -0800 |
| tree | 3bbeb3aab439796f5893f4ab70fb5cf14726745f | |
| parent | 7d5dcfca4f53f8409be59410c1b696c3dd887ecd [diff] |
Pin Pieces if we can determine they will split just by their children. (#1378) Pin Pieces if we can determine they will split just by their children. If, for example, the elements inside a ListPiece are longer than the page width when you add up all of their characters, then the ListPiece will definitely split. But the Solver will try every possible way to *not* split that Piece and waste a ton of time doing so. In particular, since the Solver reaches outermost Pieces first, it will fully explore the entire Solution tree where those don't split before finally giving up and letting them split. But the outmost Pieces also have the largest number of Solutions that can be derived from them, so the Solver gets stuck exploring entire huge pointless branches. That's unnecessary because in some cases it's obvious that a Piece will split just because of how big it's contents are. Assuming an 80-character width, a ListPiece for a collection literal is *definitely* going to split if it's contents are >80 characters long. We don't need the Solver to figure that out. This PR adds an optimization where before solving, we ask each Piece if it can be pinned to a state based just on the length of its children and whether there are any newlines in them. Then, for ListPiece and InfixPiece, we implement that optimization. Also, added a bunch of benchmarks that validate this optimization for various syntax using those pieces. With this optimization, the new formatter is now only about 30% slower than the old one on the large benchmark. (It's faster than the old formatter and slower for some of the other various benchmarks.) That's at the point where we can start looking for constant-time optimizations. \o/
The dart_style package defines an automatic, opinionated formatter for Dart code. It replaces the whitespace in your program with what it deems to be the best formatting for it. Resulting code should follow the Dart style guide but, moreso, should 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:
// BEFORE formatting if (tag=='style'||tag=='script'&&(type==null||type == TYPE_JS ||type==TYPE_DART)|| tag=='link'&&(rel=='stylesheet'||rel=='import')) {}
into:
// AFTER formatting if (tag == 'style' || tag == 'script' && (type == null || type == TYPE_JS || type == TYPE_DART) || tag == 'link' && (rel == 'stylesheet' || rel == 'import')) {}
The formatter will never break your code—you can safely invoke it automatically from build and presubmit scripts.
The formatter can also apply non-whitespace changes to make your code consistently idiomatic. You must opt into these by passing either --fix which applies all style fixes, or any of the --fix--prefixed flags to apply specific fixes.
For example, running with --fix-named-default-separator changes this:
greet(String name, {String title: "Captain"}) { print("Greetings, $title $name!"); }
into:
greet(String name, {String title = "Captain"}) { print("Greetings, $title $name!"); }
The formatter is part of the unified dart developer tool included in the Dart SDK, so most users get it directly from there. That has the latest version of the formatter that was available when the SDK was released.
IDEs and editors that support Dart usually provide easy ways to run the formatter. For example, in WebStorm you can right-click a .dart file and then choose Reformat with Dart Style.
Here's a simple example of using the formatter on the command line:
$ dart format test.dart
This command formats the test.dart file and writes the result to the file.
dart format 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 or any of its subdirectories.
By default, it formats each file and write the formatting changes to the files. If you pass --output show, it prints the formatted code to stdout.
You may pass a -l option to control the width of the page that it wraps lines to fit within, but you're strongly encouraged to keep the default line length of 80 columns.
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 .
If you need to run a different version of the formatter, you can globally activate the package from the dart_style package on pub.dev:
$ pub global activate dart_style $ pub global run dart_style:format ...
The package also exposes a single dart_style library containing a programmatic API for formatting code. Simple usage looks like this:
import 'package:dart_style/dart_style.dart'; main() { final formatter = DartFormatter(); 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.