|author||David Morgan <firstname.lastname@example.org>||Fri Nov 01 14:31:14 2019 +0100|
|committer||GitHub <email@example.com>||Fri Nov 01 14:31:14 2019 +0100|
Merge pull request #31 from davidmorgan/banhammer Mark 24 lints unused.
This package serves three purposes:
Note that everything here fits within the guidelines set out in Effective Dart. You could think of that document as the design and this package as one possible partial implementation.
See this Medium article for more background.
Here is how static analysis is used internally at Google:
TODOhint is a permanent exception.
The currently enabled lints can be found in analysis_options.1.8.0.yaml.
To use the lints add a dependency in your
# If you use `package:pedantic/pedantic.dart`, add a normal dependency. dependencies: pedantic: ^1.8.0 # Or, if you just want `analysis_options.yaml`, it can be a dev dependency. dev_dependencies: pedantic: ^1.8.0
then, add an include in your
analysis_options.yaml. If you want to always use the latest version of the lints, add a dependency on the main
If your continuous build and/or presubmit check lints then they will likely fail whenever a new version of
package:pedantic is released. To avoid this, specify a specific version of
The following lints have been considered and will not be enforced:
always_put_control_body_on_new_line violates Effective Dart “DO format your code using dartfmt”. See note about Flutter SDK style below.
always_put_required_named_parameters_first does not allow for other logical orderings of parameters, such as matching the class field order or alphabetical.
always_specify_types violates Effective Dart “AVOID type annotating initialized local variables” and others. See note about Flutter SDK style below.
avoid_annotating_with_dynamic violates Effective Dart “PREFER annotating with
dynamic instead of letting inference fail”.
avoid_as does not reflect common usage. See note about Flutter SDK style below.
avoid_catches_without_on_clauses is too strict, catching anything is useful and common even if not always the most correct thing to do.
avoid_catching_errors is too strict, the distinction between
Exception is followed closely in the SDK but is impractical to follow everywhere.
avoid_classes_with_only_static_members is too strict, Effective Dart explicitly calls out some cases (constants, enum-like types) where it makes sense to violate this lint.
avoid_double_and_int_checks only applies to web, but there is currently no mechanism for enabling a lint on web code only.
avoid_equals_and_hashcode_on_mutable_classes would require the
@immutable annotation to be consistently and correctly used everywhere.
avoid_print is too strict, it's okay to
avoid_returning_null will be obsoleted by NNBD.
avoid_returning_this has occasional false positives, and adds little value as the cascade operator for fluent interfaces in Dart is already very popular.
avoid_slow_async_io gives wrong advice if the underlying filesystem has unusual properties, for example a network mount.
avoid_void_async prevents a valid style where an asynchronous method has a
void return type to indicate that nobody should
await for the result.
cancel_subscriptions has false positives when you use a utility method or class to call
constant_identifier_names is too strict as it does not support the exceptions allowed in Effective Dart for use of ALL_CAPS.
control_flow_in_finally does not offer enough value: people are unlikely to do this by accident, and there are occasional valid uses.
directives_ordering would enforce a slightly different ordering to that used by IntelliJ and other tools using the analyzer.
empty_statements is superfluous, enforcing use of
dartfmt is sufficient to make empty statements obvious.
flutter_style_todos is for Flutter SDK internal use, see note about Flutter SDK style below.
invariant_booleans is experimental.
join_return_with_assignment does not reflect common usage.
parameter_assignments does not reflect common usage, and will cause particular problems with NNBD code.
prefer_assert_in_initializer_lists does not reflect common usage.
prefer_asserts_with_message is too strict; some asserts do not benefit from documentation.
prefer_bool_in_asserts is obsolete in Dart 2; bool is required in asserts.
prefer_const_constructors would add a lot of noise to code now that
new is optional.
prefer_constructors_over_static_methods is too strict, in some cases static methods are better.
prefer_double_quotes does not reflect common usage.
prefer_final_locals does not reflect common usage.
throw_in_finally does not offer enough value: people are unlikely to do this by accident, and there are occasional valid uses.
Note on Flutter SDK Style: some lints were created specifically to support Flutter SDK development. Flutter app developers should instead use standard Dart style as described in Effective Dart, and should not use these lints.
Please file feature requests and bugs at the issue tracker.