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.9.2
,
check out
All linter rules.
Separate the control structure expression from its statement. Specify Avoid Avoid defining a class that contains only static members. Avoid overloading operator == and hashCode on classes not marked Avoid escaping inner quotes by converting surrounding quotes. Avoid using Don't declare multiple variables on a single line. Avoid relative imports for files in 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 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. There should be no
Use 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 Avoid runtime type tests with JS interop types where the result may not
be platform-consistent. Conditions should not unconditionally evaluate to Attach library annotations to library directives. Use 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 Do not pass 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 declaring Prefer const literals as parameters of constructors on @immutable classes. Prefer defining constructors instead of static methods to create instances. Use 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 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 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 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. 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 Avoid library directives unless they have documentation comments or annotations. Don't have a library name in a Avoid Unnecessary null aware operator on extension on a nullable type. Avoid using 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. Don't access members with 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. If-elements testing for null can be replaced with null-aware elements. 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.@required
on named parameters without defaults.bool
literals in conditional expressions.@immutable
.forEach
with a function literal.lib/
.Future
-returning calls in synchronous functions unless they are assigned or returned.;
instead of {}
for empty constructor bodies.call
methods when using an object as a Function.true
or to false
.lowercase_with_underscores
when specifying a library prefix.null
check on a potentially nullable type parameter.null
as an argument where a closure is expected.const
constructors on @immutable
classes.=
to separate a named parameter from its default value.for
elements when building maps from iterables.@Deprecated("message")
.Future
results in
async
function bodies must be
await
ed or marked
unawaited
using
dart:async
.late
modifier when it is not needed.library
declaration.null
in null
-aware assignment.null
in ??
operators.this
unless avoiding shadowing.
Unless stated otherwise, the documentation on this site reflects Dart 3.9.2. Page last updated on 2025-9-8. View source or report an issue.