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.
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.
Unless stated otherwise, the documentation on this site reflects Dart 3.7.3. Page last updated on 2025-01-04. View source or report an issue.