Linter rules
Use the Dart linter to identify possible problems in your Dart code. You can use the linter through your IDE or with the dart analyze
command. For information on how to enable and disable individual linter rules, see individual rules sections of the analyzer documentation.
This page lists all the linter rules, with details such as when you might want to use each rule, what code patterns trigger it, and how you might fix your code.
Sets
#To avoid the need to individually select compatible linter rules, consider starting with a linter rule set, which the following packages provide:
- lints
- Contains two rule sets curated by the Dart team. We recommend using at least the
core
rule set, which is used when scoring packages uploaded to pub.dev. Or, better yet, use therecommended
rule set, a superset ofcore
that identifies additional issues and enforces style and format. If you're writing Flutter code, use the rule set in theflutter_lints
package, which builds onlints
.
- flutter_lints
- Contains the
flutter
rule set, which the Flutter team encourages you to use in Flutter apps, packages, and plugins. This rule set is a superset of therecommended
set, which is itself a superset of thecore
set that partially determines the score of packages uploaded to pub.dev.
To learn how to use a specific rule set, visit the documentation for enabling and disabling linter rules.
To find more predefined rule sets, check out the #lints
topic on pub.dev.
Status
#Each rule has a status or maturity level:
- Stable
- These rules are safe to use and are verified as functional with the latest versions of the Dart language. All rules are considered stable unless they're marked as experimental, deprecated, or removed.
- Experimental
- These rules are still under evaluation and might never be stabilized. Use these with caution and report any issues you come across.
- Deprecated
- These rules are no longer suggested for use and might be removed in a future Dart release.
- Removed
- These rules have already been removed in the latest stable Dart release.
Quick fixes
#Some rules can be fixed automatically using quick fixes. A quick fix is an automated edit targeted at fixing the issue reported by the linter rule.
If the rule has a quick fix, it can be applied using dart fix
or using your editor with Dart support. To learn more, see Quick fixes for analysis issues.
Rules
#The following is an index of all linter rules and a short description of their functionality. To learn more about a specific rule, click the Learn more button on its card.
For an auto-generated list containing all linter rules in Dart 3.6.0
, check out All linter rules.
Separate the control structure expression from its statement.
Specify @required
on named parameters without defaults.
Avoid bool
literals in conditional expressions.
Avoid defining a class that contains only static members.
Avoid overloading operator == and hashCode on classes not marked @immutable
.
Avoid escaping inner quotes by converting surrounding quotes.
Avoid using forEach
with a function literal.
Don't declare multiple variables on a single line.
Avoid relative imports for files in lib/
.
Don't rename parameters of overridden methods.
Avoid returning null from members whose return type is bool, double, int, or num.
Avoid single cascade in expression statements.
Avoid types as parameter names.
Avoid annotating types for function expression parameters.
Avoid overriding a final field to return different values if called multiple times.
Avoid using web-only libraries outside Flutter web plugin packages.
Prefer using lowerCamelCase for constant names.
DO use curly braces for all flow control structures.
Attach library doc comments to library directives.
Avoid using deprecated elements from within the package in which they are declared.
DO reference all public properties in debug methods.
Use ;
instead of {}
for empty constructor bodies.
Define case clauses for all constants in enum-like classes.
Use Flutter TODO format: // TODO(username): message, https://URL-to-issue.
Don't import implementation files from another package.
Explicitly tear-off call
methods when using an object as a Function.
Avoid runtime type tests with JS interop types where the result may not be platform-consistent.
Conditions should not unconditionally evaluate to true
or to false
.
Attach library annotations to library directives.
Use lowercase_with_underscores
when specifying a library prefix.
Avoid using private types in public APIs.
Don't use more than one case with same value.
Avoid leading underscores for library prefixes.
Avoid leading underscores for local identifiers.
Don't use wildcard parameters or variables.
Name non-constant identifiers using lowerCamelCase.
Don't use null
check on a potentially nullable type parameter.
Do not pass null
as an argument where a closure is expected.
Omit obvious type annotations for local variables.
Omit obvious type annotations for top-level and static variables.
Avoid defining a one-member abstract class when a simple function will do.
Prefix library names with the package name and a dot-separated path.
Use adjacent strings to concatenate string literals.
Prefer using ??=
over testing for null
.
Prefer declaring const
constructors on @immutable
classes.
Prefer const literals as parameters of constructors on @immutable classes.
Prefer defining constructors instead of static methods to create instances.
Use =
to separate a named parameter from its default value.
Use => for short members whose body is a single return statement.
Prefer final in for-each loop variable if reference is not reassigned.
Prefer final for variable declarations if they are not reassigned.
Prefer final for parameter declarations if they are not reassigned.
Prefer for
elements when building maps from iterables.
Use a function declaration to bind a function to a name.
Prefer generic function type aliases.
Prefer if elements to conditional expressions where possible.
Use interpolation to compose strings and values.
Prefer to use whereType
on iterable.
Prefer typing uninitialized variables and fields.
Don't use the Null type, unless you are positive that you don't want void.
Provide a deprecation message, via @Deprecated("message")
.
Use trailing commas for all parameter lists and argument lists.
Sort child properties last in widget instance creations.
Specify non-obvious type annotations for local variables.
Specify non-obvious type annotations for top-level and static variables.
Don't use constant patterns with type literals.
Future
results in async
function bodies must be await
ed or marked unawaited
using dart:async
.
Use of angle brackets in a doc comment is treated as HTML by Markdown.
Avoid using braces in interpolation when not needed.
Avoid wrapping fields in getters and setters just to be "safe".
Don't specify the late
modifier when it is not needed.
Avoid library directives unless they have documentation comments or annotations.
Don't have a library name in a library
declaration.
Avoid null
in null
-aware assignment.
Unnecessary null aware operator on extension on a nullable type.
Avoid using null
in ??
operators.
Use a non-nullable type for a final variable initialized with a non-nullable value.
Don't override a method to do a super method invocation with the same parameters.
Remove unnecessary backslashes in strings.
Don't access members with this
unless avoiding shadowing.
Prefer an 8-digit hexadecimal integer (for example, 0xFFFFFFFF) to instantiate a Color.
Use generic function type syntax for parameters.
Prefer intValue.isOdd/isEven instead of checking the result of % 2.
Use late for private members with a non-nullable type.
Use a setter for operations that conceptually change a property.
Use string in part of directives.
Use super-initializer parameters where possible.
Start the name of the method with to/_to or as/_as if applicable.
Unless stated otherwise, the documentation on this site reflects Dart 3.6.0. Page last updated on 2025-01-04. View source or report an issue.