Linter rules
Details about the Dart linter and its style rules you can choose.
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
corerule set, which is used when scoring packages uploaded to pub.dev. Or, better yet, use therecommendedrule set, a superset ofcorethat identifies additional issues and enforces style and format. If you're writing Flutter code, use the rule set in theflutter_lintspackage, which builds onlints.
- flutter_lints
-
Contains the
flutterrule set, which the Flutter team encourages you to use in Flutter apps, packages, and plugins. This rule set is a superset of therecommendedset, which is itself a superset of thecoreset 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.10.3,
check out All linter rules.
@required on named parameters without defaults.bool literals in conditional expressions.@immutable.forEach with a function literal.null in custom == operators.lib/.Future
-returning calls in synchronous functions unless they are assigned or returned.
; instead of {} for empty constructor bodies.hashCode if overriding ==.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.??= over testing for null.const constructors on @immutable classes.= to separate a named parameter from its default value.for elements when building maps from iterables.isNotEmpty for Iterables and Maps.whereType on iterable.@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.BuildContext across asynchronous gaps.?? operators to convert nulls to bools.Unless stated otherwise, the documentation on this site reflects Dart 3.10.3. Page last updated on 2025-10-16. View source or report an issue.