mirror of
https://github.com/flutter/flutter.git
synced 2025-06-03 00:51:18 +00:00
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)
|
||
|---|---|---|
| .. | ||
| debug_adapter | ||
| isolated | ||
| test_data | ||
| analyze_all_templates_test.dart | ||
| analyze_once_test.dart | ||
| analyze_size_test.dart | ||
| analyze_suggestions_integration_test.dart | ||
| android_e2e_api_test.dart | ||
| android_gradle_daemon_cache_test.dart | ||
| android_gradle_deprecated_plugin_apply_test.dart | ||
| android_gradle_flutter_source_path_test.dart | ||
| android_gradle_java_version_test.dart | ||
| android_gradle_outputs_app_link_settings_test.dart | ||
| android_gradle_print_build_variants_test.dart | ||
| android_plugin_compilesdkversion_mismatch_test.dart | ||
| android_plugin_example_app_build_test.dart | ||
| android_plugin_ndkversion_mismatch_test.dart | ||
| android_plugin_new_output_dir_test.dart | ||
| android_plugin_skip_unsupported_test.dart | ||
| asset_transformation_test.dart | ||
| background_isolate_test.dart | ||
| bash_entrypoint_test.dart | ||
| batch_entrypoint_test.dart | ||
| break_on_framework_exceptions_test.dart | ||
| build_ios_config_only_test.dart | ||
| build_macos_config_only_test.dart | ||
| build_preview_test.dart | ||
| cache_test.dart | ||
| command_output_test.dart | ||
| coverage_collection_test.dart | ||
| daemon_mode_test.dart | ||
| debugger_stepping_test.dart | ||
| deferred_components_test.dart | ||
| deprecated_gradle_settings_test.dart | ||
| devtools_uri_test.dart | ||
| downgrade_upgrade_integration_test.dart | ||
| exit_code_test.dart | ||
| expression_evaluation_test.dart | ||
| flutter_attach_test.dart | ||
| flutter_build_android_app_project_builddir_test.dart | ||
| flutter_build_apk_verbose_test.dart | ||
| flutter_build_config_only_test.dart | ||
| flutter_build_wasm_test.dart | ||
| flutter_build_windows_test.dart | ||
| flutter_build_with_compilation_error_test.dart | ||
| flutter_gen_test.dart | ||
| flutter_run_test.dart | ||
| flutter_run_with_error_test.dart | ||
| forbidden_imports_test.dart | ||
| gen_l10n_test.dart | ||
| gradle_non_android_plugin_test.dart | ||
| hot_reload_errors_test.dart | ||
| hot_reload_test.dart | ||
| hot_reload_with_asset_test.dart | ||
| lifetime_test.dart | ||
| observatory_port_test.dart | ||
| overall_experience_test.dart | ||
| plist_parser_test.dart | ||
| README.md | ||
| shader_compiler_test.dart | ||
| stateless_stateful_hot_reload_test.dart | ||
| swift_package_manager_create_app_test.dart | ||
| swift_package_manager_create_plugin_test.dart | ||
| swift_package_manager_test.dart | ||
| swift_package_manager_utils.dart | ||
| template_manifest_test.dart | ||
| test_driver.dart | ||
| test_test.dart | ||
| test_utils.dart | ||
| timeline_test.dart | ||
| tool_backend_test.dart | ||
| transition_test_utils.dart | ||
| unit_coverage_test.dart | ||
| variable_expansion_windows_test.dart | ||
| variable_expansion_windows.dart | ||
| vmservice_integration_test.dart | ||
| web_plugin_registrant_test.dart | ||
| xcode_backend_test.dart | ||
Integration tests
These tests are not hermetic, and use the actual Flutter SDK. While
they don't require actual devices, they run flutter_tester to test
Dart VM and Flutter integration.
Use this command to run (from the flutter_tools directory):
../../bin/cache/dart-sdk/bin/dart run test test/integration.shard
You need to have downloaded the Dart SDK in your Flutter clone for this
to work. Running ../../bin/flutter will automatically download it.
Coverage exclusion
These tests are expensive to run and do not give meaningful coverage
information for the flutter tool (since they are black-box tests that
run the tool as a subprocess, rather than being unit tests). For this
reason, they are in a separate shard when running on continuous
integration and are not run when calculating coverage.
Adding new test files
When adding a new test file make sure that it ends with _test.dart, or else it will not be run.