commit | 5298564b6407f4aae8fd6166f5d463ecccc8c890 | [log] [tgz] |
---|---|---|
author | Michael R Fairhurst <michaelrfairhurst@gmail.com> | Thu Aug 23 12:46:47 2018 -0600 |
committer | GitHub <noreply@github.com> | Thu Aug 23 12:46:47 2018 -0600 |
tree | 1c642b99e54f0fa980b352539cd20c767cfea83a | |
parent | 5c5c4a5c630e7a11def97ca48998b7f20ba655bb [diff] |
New rule: avoid_void_async. `void f() async`, suggest `Future<void>`. (#1128) * New rule: avoid_void_async. `void f() async`, suggest `Future<void>`. Fix #1122. As per discussion there, this is a *new* rule, not part of void_checks, because it is much more likely to have low false positives. In my experince, void_checks is very strict. It serves a useful purpose in pushing people away from the more complex Null type by making void useful in a way Null used to be used. However, void_checks is not required for soundness, and it seems uncommon that the theory here misses something practical. For that reason, make a new rule. Users interested in making void behave as if it were Null in certain ways can enable that, while users who just want to make sure no async functions are declared wrong can enable this. * Test on appveyor: move Stream into dart.async main file.
The Dart Linter package defines lint rules that identify and report on “lints” found in Dart Code. Linting is performed by the Dart analysis server and the dartanalyzer
commandline tool.
The linter is bundled with the Dart SDK; if you have an updated Dart SDK already, you're done!
Alternatively, if you want to contribute to the linter or examine the source, clone the linter
repo like this:
$ git clone https://github.com/dart-lang/linter.git
The linter gives you feedback to help you catch potential errors and keep your code in line with the published Dart Style Guide. Currently enforcable lint rules (or “lints”) are catalogued here and can be configured via an analysis options file. The linter is run from within the dartanalyzer
command-line tool shipped with the Dart SDK. Assuming you have lints configured in an analysis_options.yaml
file with these contents:
linter: rules: - annotate_overrides - hash_and_equals - prefer_is_not_empty
you could lint your package like this:
$ dartanalyzer --options analysis_options.yaml .
and see any violations of the annotate_overrides
, hash_and_equals
, and prefer_is_not_empty
rules in the console. To help you choose the rules you want to enable for your package, we have provided a complete list of rules, a growing list of lints according to the Effective Dart guide and a list of the lints that are enforced internally at Google.
If a specific lint warning should be ignored, it can be flagged with a comment. For example,
// ignore: avoid_as (pm as Person).firstName = 'Seth'
tells the dartanalyzer
to ignore this instance of avoid_as
warning. As lints are treated the same as errors and warnings by the analyzer, their severity can similarly be configured in an options file. For example, an analysis options file that specifies
linter: rules: - avoid_as analyzer: errors: avoid_as: error
tells the analyzer to treat avoid_as
lints as errors. For more on configuring analysis see the analysis option file docs.
Feedback is, of course, greatly appreciated and contributions are welcome! Please read the contribution guidelines; mechanics of writing lints are covered here.
Please file feature requests and bugs at the issue tracker.