5ecf10052f
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
Flutter Tools
This section of the Flutter repository contains the command line developer tools for building Flutter applications.
Working on Flutter Tools
Be sure to follow the instructions on CONTRIBUTING.md to set up your development environment. Further, familiarize yourself with the style guide, which we follow.
Setting up
First, ensure that the Dart SDK and other necessary artifacts are available by invoking the Flutter Tools wrapper script. In this directory run:
$ flutter --version
Running the Tool
To run Flutter Tools from source, in this directory run:
$ dart bin/flutter_tools.dart
followed by command-line arguments, as usual.
As a convenience for folks developing the flutter tool itself,
you can also use the bin/flutter-dev script:
# Assuming flutter/bin is on your PATH
$ flutter-dev
Note: flutter-dev is identical to flutter, except it does not
use a cached on-disk snapshot. In other words, it will be significantly
slower but you will not need to forget (remember?) to delete the cached
snapshot.
Running the analyzer
To run the analyzer on Flutter Tools, in this directory run:
$ flutter analyze
Writing tests
As with other parts of the Flutter repository, all changes in behavior
must be tested.
Tests live under the test/ subdirectory.
-
Hermetic unit tests of tool internals go under
test/general.shardand must run in significantly less than two seconds. -
Tests of tool commands go under
test/commands.shard. Hermetic tests go under itshermetic/subdirectory. Non-hermetic tests go under itspermeablesub-directory. Avoid adding tests here and prefer writing either a unit test or a full integration test. -
Integration tests (e.g. tests that run the tool in a subprocess) go under
test/integration.shard. -
Slow web-related tests go in the
test/web.sharddirectory.
In general, the tests for the code in a file called file.dart should
go in a file called file_test.dart in the subdirectory that matches
the behavior of the test.
The dart_test.yaml file configures the timeout for these tests to be
15 minutes. The test.dart script that is used in CI overrides this
to two seconds for the test/general.shard directory, to catch
behaviour that is unexpectedly slow.
Please avoid setting any other timeouts.
Using local engine builds in integration tests
The integration tests can be configured to use a specific local engine
variant by setting the FLUTTER_LOCAL_ENGINE and FLUTTER_LOCAL_ENGINE_HOST
environment variables to the name of the local engines (e.g. android_debug_unopt
and host_debug_unopt). If the local engine build requires a source path, this
can be provided by setting the FLUTTER_LOCAL_ENGINE_SRC_PATH environment
variable. This second variable is not necessary if the flutter and engine
checkouts are in adjacent directories.
export FLUTTER_LOCAL_ENGINE=android_debug_unopt
export FLUTTER_LOCAL_ENGINE_HOST=host_debug_unopt
flutter test test/integration.shard/some_test_case
Running the tests
To run all of the unit tests:
$ flutter test test/general.shard
The tests in test/integration.shard are slower to run than the tests
in test/general.shard. Depending on your development computer, you
might want to limit concurrency. Generally it is easier to run these
on CI, or to manually verify the behavior you are changing instead of
running the test.
The integration tests also require the FLUTTER_ROOT environment
variable to be set. The full invocation to run everything might
therefore look something like:
$ export FLUTTER_ROOT=~/path/to/flutter-sdk
$ flutter test --concurrency 1
This may take some time (on the order of an hour). The unit tests alone take much less time (on the order of a minute).
You can run the tests in a specific file, e.g.:
$ flutter test test/general.shard/utils_test.dart
Forcing snapshot regeneration
To force the Flutter Tools snapshot to be regenerated, delete the following files:
$ rm ../../bin/cache/flutter_tools.stamp ../../bin/cache/flutter_tools.snapshot