Google Git
Sign in
dart / sdk / ffd90043140b082c478f43137691a36e1cf8ba18 / . / pkg / linter / messages.yaml
blob: ce3b3fd4e84e27c9b40a6db38b09d27876a9f5c1 [file] [log] [blame]
# Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file
# for details. All rights reserved. Use of this source code is governed by a
# BSD-style license that can be found in the LICENSE file.
LintCode:
always_declare_return_types_of_functions:
sharedName: always_declare_return_types
problemMessage: "The function '{0}' should have a return type but doesn't."
correctionMessage: "Try adding a return type to the function."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a method or function doesn't
have an explicit return type.
#### Example
The following code produces this diagnostic because the function `f`
doesn't have a return type:
```dart
[!f!]() {}
```
#### Common fixes
Add an explicit return type:
```dart
void f() {}
```
always_declare_return_types_of_methods:
sharedName: always_declare_return_types
problemMessage: "The method '{0}' should have a return type but doesn't."
correctionMessage: "Try adding a return type to the method."
hasPublishedDocs: true
always_put_control_body_on_new_line:
problemMessage: "Statement should be on a separate line."
correctionMessage: "Try moving the statement to a new line."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the code being controlled by a
control flow statement (`if`, `for`, `while`, or `do`) is on the same line
as the control flow statement.
#### Example
The following code produces this diagnostic because the `return` statement
is on the same line as the `if` that controls whether the `return` will be
executed:
```dart
void f(bool b) {
if (b) [!return!];
}
```
#### Common fixes
Put the controlled statement onto a separate, indented, line:
```dart
void f(bool b) {
if (b)
return;
}
```
always_put_required_named_parameters_first:
problemMessage: "Required named parameters should be before optional named parameters."
correctionMessage: "Try moving the required named parameter to be before any optional named parameters."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when required named parameters occur
after optional named parameters.
#### Example
The following code produces this diagnostic because the required parameter
`x` is after the optional parameter `y`:
```dart
void f({int? y, required int [!x!]}) {}
```
#### Common fixes
Reorder the parameters so that all required named parameters are before
any optional named parameters:
```dart
void f({required int x, int? y}) {}
```
always_require_non_null_named_parameters:
removedIn: "3.3"
always_specify_types_add_type:
sharedName: always_specify_types
problemMessage: "Missing type annotation."
correctionMessage: "Try adding a type annotation."
hasPublishedDocs: false
always_specify_types_replace_keyword:
sharedName: always_specify_types
problemMessage: "Missing type annotation."
correctionMessage: "Try replacing '{0}' with '{1}'."
hasPublishedDocs: false
always_specify_types_specify_type:
sharedName: always_specify_types
problemMessage: "Missing type annotation."
correctionMessage: "Try specifying the type '{0}'."
hasPublishedDocs: false
always_specify_types_split_to_types:
sharedName: always_specify_types
problemMessage: "Missing type annotation."
correctionMessage: "Try splitting the declaration and specify the different type annotations."
hasPublishedDocs: false
always_use_package_imports:
problemMessage: "Use 'package:' imports for files in the 'lib' directory."
correctionMessage: "Try converting the URI to a 'package:' URI."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an `import` in a library inside
the `lib` directory uses a relative path to import another library inside
the `lib` directory of the same package.
#### Example
Given that a file named `a.dart` and the code below are both inside the
`lib` directory of the same package, the following code produces this
diagnostic because a relative URI is used to import `a.dart`:
```dart
import [!'a.dart'!];
```
#### Common fixes
Use a package import:
```dart
import 'package:p/a.dart';
```
annotate_overrides:
problemMessage: "The member '{0}' overrides an inherited member but isn't annotated with '@override'."
correctionMessage: "Try adding the '@override' annotation."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a member overrides an inherited
member, but isn't annotated with `@override`.
#### Example
The following code produces this diagnostic because the method `m` in the
class `B` overrides the method with the same name in class `A`, but isn't
marked as an intentional override:
```dart
class A {
void m() {}
}
class B extends A {
void [!m!]() {}
}
```
#### Common fixes
If the member in the subclass is intended to override the member in the
superclass, then add an `@override` annotation:
```dart
class A {
void m() {}
}
class B extends A {
@override
void m() {}
}
```
If the member in the subclass is not intended to override the member in
the superclass, then rename one of the members:
```dart
class A {
void m() {}
}
class B extends A {
void m2() {}
}
```
annotate_redeclares:
problemMessage: "The member '{0}' is redeclaring but isn't annotated with '@redeclare'."
correctionMessage: "Try adding the '@redeclare' annotation."
hasPublishedDocs: false
avoid_annotating_with_dynamic:
problemMessage: "Unnecessary 'dynamic' type annotation."
correctionMessage: "Try removing the type 'dynamic'."
hasPublishedDocs: false
avoid_as:
removedIn: "3.0"
avoid_bool_literals_in_conditional_expressions:
problemMessage: "Conditional expressions with a 'bool' literal can be simplified."
correctionMessage: "Try rewriting the expression to use either '&&' or '||'."
hasPublishedDocs: false
avoid_catches_without_on_clauses:
problemMessage: "Catch clause should use 'on' to specify the type of exception being caught."
correctionMessage: "Try adding an 'on' clause before the 'catch'."
hasPublishedDocs: false
avoid_catching_errors_class:
sharedName: avoid_catching_errors
problemMessage: "The type 'Error' should not be caught."
correctionMessage: "Try removing the catch or catching an 'Exception' instead."
hasPublishedDocs: false
avoid_catching_errors_subclass:
sharedName: avoid_catching_errors
problemMessage: "The type '{0}' should not be caught because it is a subclass of 'Error'."
correctionMessage: "Try removing the catch or catching an 'Exception' instead."
hasPublishedDocs: false
avoid_classes_with_only_static_members:
problemMessage: "Classes should define instance members."
correctionMessage: "Try adding instance behavior or moving the members out of the class."
hasPublishedDocs: false
avoid_double_and_int_checks:
problemMessage: "Explicit check for double or int."
correctionMessage: "Try removing the check."
hasPublishedDocs: false
avoid_dynamic_calls:
problemMessage: "Method invocation or property access on a 'dynamic' target."
correctionMessage: "Try giving the target a type."
hasPublishedDocs: false
avoid_empty_else:
problemMessage: "Empty statements are not allowed in an 'else' clause."
correctionMessage: "Try removing the empty statement or removing the else clause."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the statement after an `else`
is an empty statement (a semicolon).
For more information, see the documentation for
[`avoid_empty_else`](https://dart.dev/diagnostics/avoid_empty_else).
#### Example
The following code produces this diagnostic because the statement
following the `else` is an empty statement:
```dart
void f(int x, int y) {
if (x > y)
print("1");
else [!;!]
print("2");
}
```
#### Common fixes
If the statement after the empty statement is intended to be executed only
when the condition is `false`, then remove the empty statement:
```dart
void f(int x, int y) {
if (x > y)
print("1");
else
print("2");
}
```
If there is no code that is intended to be executed only when the
condition is `false`, then remove the whole `else` clause:
```dart
void f(int x, int y) {
if (x > y)
print("1");
print("2");
}
```
avoid_equals_and_hash_code_on_mutable_classes:
problemMessage: "The method '{0}' should not be overridden in classes not annotated with '@immutable'."
correctionMessage: "Try removing the override or annotating the class with '@immutable'."
hasPublishedDocs: false
avoid_escaping_inner_quotes:
problemMessage: "Unnecessary escape of '{0}'."
correctionMessage: "Try changing the outer quotes to '{1}'."
hasPublishedDocs: false
avoid_field_initializers_in_const_classes:
problemMessage: "Fields in 'const' classes should not have initializers."
correctionMessage: "Try converting the field to a getter or initialize the field in the constructors."
hasPublishedDocs: false
avoid_final_parameters:
problemMessage: "Parameters should not be marked as 'final'."
correctionMessage: "Try removing the keyword 'final'."
hasPublishedDocs: false
avoid_function_literals_in_foreach_calls:
problemMessage: "Function literals shouldn't be passed to 'forEach'."
correctionMessage: "Try using a 'for' loop."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the argument to
`Iterable.forEach` is a closure.
#### Example
The following code produces this diagnostic because the argument to the
invocation of `forEach` is a closure:
```dart
void f(Iterable<String> s) {
s.[!forEach!]((e) => print(e));
}
```
#### Common fixes
If the closure can be replaced by a tear-off, then replace the closure:
```dart
void f(Iterable<String> s) {
s.forEach(print);
}
```
If the closure can't be replaced by a tear-off, then use a `for` loop to
iterate over the elements:
```dart
void f(Iterable<String> s) {
for (var e in s) {
print(e);
}
}
```
avoid_implementing_value_types:
problemMessage: "Classes that override '==' should not be implemented."
correctionMessage: "Try removing the class from the 'implements' clause."
hasPublishedDocs: false
avoid_init_to_null:
problemMessage: "Redundant initialization to 'null'."
correctionMessage: "Try removing the initializer."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a nullable variable is
explicitly initialized to `null`. The variable can be a local variable,
field, or top-level variable.
A variable or field that isn't explicitly initialized automatically gets
initialized to `null`. There's no concept of "uninitialized memory" in
Dart.
#### Example
The following code produces this diagnostic because the variable `f` is
explicitly initialized to `null`:
```dart
class C {
int? [!f = null!];
void m() {
if (f != null) {
print(f);
}
}
}
```
#### Common fixes
Remove the unnecessary initialization:
```dart
class C {
int? f;
void m() {
if (f != null) {
print(f);
}
}
}
```
avoid_js_rounded_ints:
problemMessage: "Integer literal can't be represented exactly when compiled to JavaScript."
correctionMessage: "Try using a 'BigInt' to represent the value."
hasPublishedDocs: false
avoid_multiple_declarations_per_line:
problemMessage: "Multiple variables declared on a single line."
correctionMessage: "Try splitting the variable declarations into multiple lines."
hasPublishedDocs: false
avoid_null_checks_in_equality_operators:
problemMessage: "Unnecessary null comparison in implementation of '=='."
correctionMessage: "Try removing the comparison."
hasPublishedDocs: false
avoid_positional_boolean_parameters:
problemMessage: "'bool' parameters should be named parameters."
correctionMessage: "Try converting the parameter to a named parameter."
hasPublishedDocs: false
avoid_print:
problemMessage: "Don't invoke 'print' in production code."
correctionMessage: "Try using a logging framework."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the function `print` is invoked
in production code.
#### Example
The following code produces this diagnostic because the function `print`
can't be invoked in production:
```dart
void f(int x) {
[!print!]('x = $x');
}
```
#### Common fixes
If you're writing code that uses Flutter, then use the function
[`debugPrint`][debugPrint], guarded by a test
using [`kDebugMode`][kDebugMode]:
```dart
import 'package:flutter/foundation.dart';
void f(int x) {
if (kDebugMode) {
debugPrint('x = $x');
}
}
```
If you're writing code that doesn't use Flutter, then use a logging
service, such as [`package:logging`][package-logging], to write the
information.
avoid_private_typedef_functions:
problemMessage: "The typedef is unnecessary because it is only used in one place."
correctionMessage: "Try inlining the type or using it in other places."
hasPublishedDocs: false
avoid_redundant_argument_values:
problemMessage: "The value of the argument is redundant because it matches the default value."
correctionMessage: "Try removing the argument."
hasPublishedDocs: false
avoid_relative_lib_imports:
problemMessage: "Can't use a relative path to import a library in 'lib'."
correctionMessage: "Try fixing the relative path or changing the import to a 'package:' import."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the URI in an `import`
directive has `lib` in the path.
#### Example
Assuming that there is a file named `a.dart` in the `lib` directory:
```dart
%uri="lib/a.dart"
class A {}
```
The following code produces this diagnostic because the import contains a
path that includes `lib`:
```dart
import [!'../lib/a.dart'!];
```
#### Common fixes
Rewrite the import to not include `lib` in the URI:
```dart
import 'a.dart';
```
avoid_renaming_method_parameters:
problemMessage: "The parameter name '{0}' doesn't match the name '{1}' in the overridden method."
correctionMessage: "Try changing the name to '{1}'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a method that overrides a
method from a superclass changes the names of the parameters.
#### Example
The following code produces this diagnostic because the parameter of the
method `m` in `B` is named `b`, which is different from the name of the
overridden method's parameter in `A`:
```dart
class A {
void m(int a) {}
}
class B extends A {
@override
void m(int [!b!]) {}
}
```
#### Common fixes
Rename one of the parameters so that they are the same:
```dart
class A {
void m(int a) {}
}
class B extends A {
@override
void m(int a) {}
}
```
avoid_return_types_on_setters:
problemMessage: "Unnecessary return type on a setter."
correctionMessage: "Try removing the return type."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a setter has an explicit return
type.
Setters never return a value, so declaring the return type of one is
redundant.
#### Example
The following code produces this diagnostic because the setter `s` has an
explicit return type (`void`):
```dart
[!void!] set s(int p) {}
```
#### Common fixes
Remove the return type:
```dart
set s(int p) {}
```
avoid_returning_null:
removedIn: "3.3"
avoid_returning_null_for_future:
removedIn: "3.3"
avoid_returning_null_for_void_from_function:
sharedName: avoid_returning_null_for_void
problemMessage: "Don't return 'null' from a function with a return type of 'void'."
correctionMessage: "Try removing the 'null'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a function that has a return
type of `void` explicitly returns `null`.
#### Example
The following code produces this diagnostic because there is an explicit
return of `null` in a `void` function:
```dart
void f() {
[!return null;!]
}
```
#### Common fixes
Remove the unnecessary explicit `null`:
```dart
void f() {
return;
}
```
avoid_returning_null_for_void_from_method:
sharedName: avoid_returning_null_for_void
problemMessage: "Don't return 'null' from a method with a return type of 'void'."
correctionMessage: "Try removing the 'null'."
hasPublishedDocs: true
avoid_returning_this:
problemMessage: "Don't return 'this' from a method."
correctionMessage: "Try changing the return type to 'void' and removing the return."
hasPublishedDocs: false
avoid_setters_without_getters:
problemMessage: "Setter has no corresponding getter."
correctionMessage: "Try adding a corresponding getter or removing the setter."
hasPublishedDocs: false
avoid_shadowing_type_parameters:
problemMessage: "The type parameter '{0}' shadows a type parameter from the enclosing {1}."
correctionMessage: "Try renaming one of the type parameters."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a type parameter shadows a type
parameter from an enclosing declaration.
Shadowing a type parameter with a different type parameter can lead to
subtle bugs that are difficult to debug.
#### Example
The following code produces this diagnostic because the type parameter `T`
defined by the method `m` shadows the type parameter `T` defined by the
class `C`:
```dart
class C<T> {
void m<[!T!]>() {}
}
```
#### Common fixes
Rename one of the type parameters:
```dart
class C<T> {
void m<S>() {}
}
```
avoid_single_cascade_in_expression_statements:
problemMessage: "Unnecessary cascade expression."
correctionMessage: "Try using the operator '{0}'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a single cascade operator is
used and the value of the expression isn't being used for anything (such
as being assigned to a variable or being passed as an argument).
#### Example
The following code produces this diagnostic because the value of the
cascade expression `s..length` isn't being used:
```dart
void f(String s) {
[!s..length!];
}
```
#### Common fixes
Replace the cascade operator with a simple access operator:
```dart
void f(String s) {
s.length;
}
```
avoid_slow_async_io:
problemMessage: "Use of an async 'dart:io' method."
correctionMessage: "Try using the synchronous version of the method."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an asynchronous file I/O method
with a synchronous equivalent is used.
The following are the specific flagged asynchronous methods:
- `Directory.exists`
- `Directory.stat`
- `File.lastModified`
- `File.exists`
- `File.stat`
- `FileSystemEntity.isDirectory`
- `FileSystemEntity.isFile`
- `FileSystemEntity.isLink`
- `FileSystemEntity.type`
#### Example
The following code produces this diagnostic because the async method
`exists` is invoked:
```dart
import 'dart:io';
Future<void> g(File f) async {
await [!f.exists()!];
}
```
#### Common fixes
Use the synchronous version of the method:
```dart
import 'dart:io';
void g(File f) {
f.existsSync();
}
```
avoid_type_to_string:
problemMessage: "Using 'toString' on a 'Type' is not safe in production code."
correctionMessage: "Try a normal type check or compare the 'runtimeType' directly."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the method `toString` is
invoked on a value whose static type is `Type`.
#### Example
The following code produces this diagnostic because the method `toString`
is invoked on the `Type` returned by `runtimeType`:
```dart
bool isC(Object o) => o.runtimeType.[!toString!]() == 'C';
class C {}
```
#### Common fixes
If it's essential that the type is exactly the same, then use an explicit
comparison:
```dart
bool isC(Object o) => o.runtimeType == C;
class C {}
```
If it's alright for instances of subtypes of the type to return `true`,
then use a type check:
```dart
bool isC(Object o) => o is C;
class C {}
```
avoid_types_as_parameter_names:
problemMessage: "The parameter name '{0}' matches a visible type name."
correctionMessage: "Try adding a name for the parameter or changing the parameter name to not match an existing type."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a parameter in a
parameter list is the same as a visible type (a type whose name is in
scope).
This often indicates that the intended name of the parameter is missing,
causing the name of the type to be used as the name of the parameter
rather than the type of the parameter. Even when that's not the case (the
name of the parameter is intentional), the name of the parameter will
shadow the existing type, which can lead to bugs that are difficult to
diagnose.
#### Example
The following code produces this diagnostic because the function `f` has a
parameter named `int`, which shadows the type `int` from `dart:core`:
```dart
void f([!int!]) {}
```
#### Common fixes
If the parameter name is missing, then add a name for the parameter:
```dart
void f(int x) {}
```
If the parameter is intended to have an implicit type of `dynamic`, then
rename the parameter so that it doesn't shadow the name of any visible type:
```dart
void f(int_) {}
```
avoid_types_on_closure_parameters:
problemMessage: "Unnecessary type annotation on a function expression parameter."
correctionMessage: "Try removing the type annotation."
hasPublishedDocs: false
avoid_unnecessary_containers:
problemMessage: "Unnecessary instance of 'Container'."
correctionMessage: "Try removing the 'Container' (but not its children) from the widget tree."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a widget tree contains an
instance of `Container` and the only argument to the constructor is
`child:`.
#### Example
The following code produces this diagnostic because the invocation of the
`Container` constructor only has a `child:` argument:
```dart
import 'package:flutter/material.dart';
Widget buildRow() {
return [!Container!](
child: Row(
children: [
Text('a'),
Text('b'),
],
)
);
}
```
#### Common fixes
If you intended to provide other arguments to the constructor, then add
them:
```dart
import 'package:flutter/material.dart';
Widget buildRow() {
return Container(
color: Colors.red.shade100,
child: Row(
children: [
Text('a'),
Text('b'),
],
)
);
}
```
If no other arguments are needed, then unwrap the child widget:
```dart
import 'package:flutter/material.dart';
Widget buildRow() {
return Row(
children: [
Text('a'),
Text('b'),
],
);
}
```
avoid_unstable_final_fields:
removedIn: "3.3"
avoid_unused_constructor_parameters:
problemMessage: "The parameter '{0}' is not used in the constructor."
correctionMessage: "Try using the parameter or removing it."
hasPublishedDocs: false
avoid_void_async:
problemMessage: "An 'async' function should have a 'Future' return type when it doesn't return a value."
correctionMessage: "Try changing the return type."
hasPublishedDocs: false
avoid_web_libraries_in_flutter:
problemMessage: "Don't use web-only libraries outside Flutter web plugins."
correctionMessage: "Try finding a different library for your needs."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a library in a package that
isn't a web plugin contains an import of a web-only library:
- `dart:html`
- `dart:js`
- `dart:js_util`
- `dart:js_interop`
- `dart:js_interop_unsafe`
- `package:js`
- `package:web`
#### Example
When found in a package that isn't a web plugin, the following code
produces this diagnostic because it imports `dart:html`:
```dart
import [!'dart:html'!];
import 'package:flutter/material.dart';
class C {}
```
#### Common fixes
If the package isn't intended to be a web plugin, then remove the import:
```dart
import 'package:flutter/material.dart';
class C {}
```
If the package is intended to be a web plugin, then add the following
lines to the `pubspec.yaml` file of the package:
```yaml
flutter:
plugin:
platforms:
web:
pluginClass: HelloPlugin
fileName: hello_web.dart
```
See [Developing packages & plugins](https://flutter.dev/to/develop-packages)
for more information.
await_only_futures:
problemMessage: "Uses 'await' on an instance of '{0}', which is not a subtype of 'Future'."
correctionMessage: "Try removing the 'await' or changing the expression."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the expression after `await`
has any type other than `Future<T>`, `FutureOr<T>`, `Future<T>?`,
`FutureOr<T>?` or `dynamic`.
An exception is made for the expression `await null` because it is a
common way to introduce a microtask delay.
Unless the expression can produce a `Future`, the `await` is unnecessary
and can cause a reader to assume a level of asynchrony that doesn't exist.
#### Example
The following code produces this diagnostic because the expression after
`await` has the type `int`:
```dart
void f() async {
[!await!] 23;
}
```
#### Common fixes
Remove the `await`:
```dart
void f() async {
23;
}
```
camel_case_extensions:
problemMessage: "The extension name '{0}' isn't an UpperCamelCase identifier."
correctionMessage: "Try changing the name to follow the UpperCamelCase style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of an extension
doesn't use the 'UpperCamelCase' naming convention.
#### Example
The following code produces this diagnostic because the name of the
extension doesn't start with an uppercase letter:
```dart
extension [!stringExtension!] on String {}
```
#### Common fixes
If the extension needs to have a name (needs to be visible outside this
library), then rename the extension so that it has a valid name:
```dart
extension StringExtension on String {}
```
If the extension doesn't need to have a name, then remove the name of the
extension:
```dart
extension on String {}
```
camel_case_types:
problemMessage: "The type name '{0}' isn't an UpperCamelCase identifier."
correctionMessage: "Try changing the name to follow the UpperCamelCase style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a type (a class,
mixin, enum, or typedef) doesn't use the 'UpperCamelCase' naming
convention.
#### Example
The following code produces this diagnostic because the name of the class
doesn't start with an uppercase letter:
```dart
class [!c!] {}
```
#### Common fixes
Rename the type so that it has a valid name:
```dart
class C {}
```
cancel_subscriptions:
problemMessage: "Uncancelled instance of 'StreamSubscription'."
correctionMessage: "Try invoking 'cancel' in the function in which the 'StreamSubscription' was created."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an instance of
`StreamSubscription` is created but the method `cancel` isn't invoked.
#### Example
The following code produces this diagnostic because the `subscription`
isn't canceled:
```dart
import 'dart:async';
void f(Stream stream) {
// ignore: unused_local_variable
var [!subscription = stream.listen((_) {})!];
}
```
#### Common fixes
Cancel the subscription:
```dart
import 'dart:async';
void f(Stream stream) {
var subscription = stream.listen((_) {});
subscription.cancel();
}
```
cascade_invocations:
problemMessage: "Unnecessary duplication of receiver."
correctionMessage: "Try using a cascade to avoid the duplication."
hasPublishedDocs: false
cast_nullable_to_non_nullable:
problemMessage: "Don't cast a nullable value to a non-nullable type."
correctionMessage: "Try adding a not-null assertion ('!') to make the type non-nullable."
hasPublishedDocs: false
close_sinks:
problemMessage: "Unclosed instance of 'Sink'."
correctionMessage: "Try invoking 'close' in the function in which the 'Sink' was created."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an instance of `Sink` is
created but the method `close` isn't invoked.
#### Example
The following code produces this diagnostic because the `sink` isn't
closed:
```dart
import 'dart:io';
void g(File f) {
var [!sink = f.openWrite()!];
sink.write('x');
}
```
#### Common fixes
Close the sink:
```dart
import 'dart:io';
void g(File f) {
var sink = f.openWrite();
sink.write('x');
sink.close();
}
```
collection_methods_unrelated_type:
problemMessage: "The argument type '{0}' isn't related to '{1}'."
correctionMessage: "Try changing the argument or element type to match."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when any one of several methods in
the core libraries are invoked with arguments of an inappropriate type.
These methods are ones that don't provide a specific enough type for the
parameter to allow the normal type checking to catch the error.
The arguments that are checked are:
- an argument to `Iterable<E>.contains` should be related to `E`
- an argument to `List<E>.remove` should be related to `E`
- an argument to `Map<K, V>.containsKey` should be related to `K`
- an argument to `Map<K, V>.containsValue` should be related to `V`
- an argument to `Map<K, V>.remove` should be related to `K`
- an argument to `Map<K, V>.[]` should be related to `K`
- an argument to `Queue<E>.remove` should be related to `E`
- an argument to `Set<E>.lookup` should be related to `E`
- an argument to `Set<E>.remove` should be related to `E`
#### Example
The following code produces this diagnostic because the argument to
`contains` is a `String`, which isn't assignable to `int`, the element
type of the list `l`:
```dart
bool f(List<int> l) => l.contains([!'1'!]);
```
#### Common fixes
If the element type is correct, then change the argument to have the same
type:
```dart
bool f(List<int> l) => l.contains(1);
```
If the argument type is correct, then change the element type:
```dart
bool f(List<String> l) => l.contains('1');
```
combinators_ordering:
problemMessage: "Sort combinator names alphabetically."
correctionMessage: "Try sorting the combinator names alphabetically."
hasPublishedDocs: false
comment_references:
problemMessage: "The referenced name isn't visible in scope."
correctionMessage: "Try adding an import for the referenced name."
hasPublishedDocs: false
conditional_uri_does_not_exist:
problemMessage: "The target of the conditional URI '{0}' doesn't exist."
correctionMessage: "Try creating the file referenced by the URI, or try using a URI for a file that does exist."
hasPublishedDocs: false
constant_identifier_names:
problemMessage: "The constant name '{0}' isn't a lowerCamelCase identifier."
correctionMessage: "Try changing the name to follow the lowerCamelCase style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a constant doesn't
follow the lowerCamelCase naming convention.
#### Example
The following code produces this diagnostic because the name of the
top-level variable isn't a lowerCamelCase identifier:
```dart
const [!EMPTY_STRING!] = '';
```
#### Common fixes
Rewrite the name to follow the lowerCamelCase naming convention:
```dart
const emptyString = '';
```
control_flow_in_finally:
problemMessage: "Use of '{0}' in a 'finally' clause."
correctionMessage: "Try restructuring the code."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a `finally` clause contains a
`return`, `break`, or `continue` statement.
#### Example
The following code produces this diagnostic because there is a `return`
statement inside a `finally` block:
```dart
int f() {
try {
return 1;
} catch (e) {
print(e);
} finally {
[!return 0;!]
}
}
```
#### Common fixes
If the statement isn't needed, then remove the statement, and remove the
`finally` clause if the block is empty:
```dart
int f() {
try {
return 1;
} catch (e) {
print(e);
}
}
```
If the statement is needed, then move the statement outside the `finally`
block:
```dart
int f() {
try {
return 1;
} catch (e) {
print(e);
}
return 0;
}
```
curly_braces_in_flow_control_structures:
problemMessage: "Statements in {0} should be enclosed in a block."
correctionMessage: "Try wrapping the statement in a block."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a control structure (`if`,
`for`, `while`, or `do` statement) has a statement other than a block.
#### Example
The following code produces this diagnostic because the `then` statement
is not enclosed in a block:
```dart
int f(bool b) {
if (b)
[!return 1;!]
return 0;
}
```
#### Common fixes
Add braces around the statement that should be a block:
```dart
int f(bool b) {
if (b) {
return 1;
}
return 0;
}
```
dangling_library_doc_comments:
problemMessage: "Dangling library doc comment."
correctionMessage: "Add a 'library' directive after the library comment."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a documentation comment that
appears to be library documentation isn't followed by a `library`
directive. More specifically, it is produced when a documentation comment
appears before the first directive in the library, assuming that it isn't
a `library` directive, or before the first top-level declaration and is
separated from the declaration by one or more blank lines.
#### Example
The following code produces this diagnostic because there's a
documentation comment before the first `import` directive:
```dart
[!/// This is a great library.!]
import 'dart:core';
```
The following code produces this diagnostic because there's a
documentation comment before the first class declaration, but there's a
blank line between the comment and the declaration.
```dart
[!/// This is a great library.!]
class C {}
```
#### Common fixes
If the comment is library documentation, then add a `library` directive
without a name:
```dart
/// This is a great library.
library;
import 'dart:core';
```
If the comment is documentation for the following declaration, then remove
the blank line:
```dart
/// This is a great library.
class C {}
```
depend_on_referenced_packages:
problemMessage: "The imported package '{0}' isn't a dependency of the importing package."
correctionMessage: "Try adding a dependency for '{0}' in the 'pubspec.yaml' file."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a package import refers to a
package that is not specified in the `pubspec.yaml` file.
Depending explicitly on packages that you reference ensures they will
always exist and allows you to put a dependency constraint on them to
guard against breaking changes.
#### Example
Given a `pubspec.yaml` file containing the following:
```yaml
dependencies:
meta: ^3.0.0
```
The following code produces this diagnostic because there is no dependency
on the package `a`:
```dart
import 'package:a/a.dart';
```
#### Common fixes
Whether the dependency should be a regular dependency or dev dependency
depends on whether the package is referenced from a public library (one
under either `lib` or `bin`), or only private libraries, (such as one
under `test`).
If the package is referenced from at least one public library, then add a
regular dependency on the package to the `pubspec.yaml` file under the
`dependencies` field:
```yaml
dependencies:
a: ^1.0.0
meta: ^3.0.0
```
If the package is referenced only from private libraries, then add a
dev dependency on the package to the `pubspec.yaml` file under the
`dev_dependencies` field:
```yaml
dependencies:
meta: ^3.0.0
dev_dependencies:
a: ^1.0.0
```
deprecated_consistency_constructor:
sharedName: deprecated_consistency
problemMessage: "Constructors in a deprecated class should be deprecated."
correctionMessage: "Try marking the constructor as deprecated."
hasPublishedDocs: false
deprecated_consistency_parameter:
sharedName: deprecated_consistency
problemMessage: "Parameters that initialize a deprecated field should be deprecated."
correctionMessage: "Try marking the parameter as deprecated."
hasPublishedDocs: false
deprecated_consistency_field:
sharedName: deprecated_consistency
problemMessage: "Fields that are initialized by a deprecated parameter should be deprecated."
correctionMessage: "Try marking the field as deprecated."
hasPublishedDocs: false
deprecated_member_use_from_same_package_with_message:
sharedName: deprecated_member_use_from_same_package
problemMessage: "'{0}' is deprecated and shouldn't be used. {1}"
correctionMessage: "Try replacing the use of the deprecated member with the replacement, if a replacement is specified."
hasPublishedDocs: false
deprecated_member_use_from_same_package_without_message:
sharedName: deprecated_member_use_from_same_package
problemMessage: "'{0}' is deprecated and shouldn't be used."
correctionMessage: "Try replacing the use of the deprecated member with the replacement, if a replacement is specified."
hasPublishedDocs: false
diagnostic_describe_all_properties:
problemMessage: "The public property isn't described by either 'debugFillProperties' or 'debugDescribeChildren'."
correctionMessage: "Try describing the property."
hasPublishedDocs: false
directives_ordering_alphabetical:
sharedName: directives_ordering
problemMessage: "Sort directive sections alphabetically."
correctionMessage: "Try sorting the directives."
hasPublishedDocs: false
directives_ordering_dart:
sharedName: directives_ordering
problemMessage: "Place 'dart:' {0}s before other {0}s."
correctionMessage: "Try sorting the directives."
hasPublishedDocs: false
directives_ordering_exports:
sharedName: directives_ordering
problemMessage: "Specify exports in a separate section after all imports."
correctionMessage: "Try sorting the directives."
hasPublishedDocs: false
directives_ordering_package_before_relative:
sharedName: directives_ordering
problemMessage: "Place 'package:' {0}s before relative {0}s."
correctionMessage: "Try sorting the directives."
hasPublishedDocs: false
discarded_futures:
problemMessage: "Asynchronous function invoked in a non-'async' function."
correctionMessage: "Try converting the enclosing function to be 'async' and then 'await' the future."
hasPublishedDocs: false
do_not_use_environment:
problemMessage: "Invalid use of an environment declaration."
correctionMessage: "Try removing the environment declaration usage."
hasPublishedDocs: false
document_ignores:
problemMessage: "Missing documentation explaining why the diagnostic is ignored."
correctionMessage: "Try adding a comment immediately above the ignore comment."
hasPublishedDocs: false
empty_catches:
problemMessage: "Empty catch block."
correctionMessage: "Try adding statements to the block, adding a comment to the block, or removing the 'catch' clause."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the block in a `catch` clause
is empty.
#### Example
The following code produces this diagnostic because the catch block is
empty:
```dart
void f() {
try {
print('Hello');
} catch (exception) [!{}!]
}
```
#### Common fixes
If the exception shouldn't be ignored, then add code to handle the
exception:
```dart
void f() {
try {
print('We can print.');
} catch (exception) {
print("We can't print.");
}
}
```
If the exception is intended to be ignored, then add a comment explaining
why:
```dart
void f() {
try {
print('We can print.');
} catch (exception) {
// Nothing to do.
}
}
```
If the exception is intended to be ignored and there isn't any good
explanation for why, then rename the exception parameter:
```dart
void f() {
try {
print('We can print.');
} catch (_) {}
}
```
empty_constructor_bodies:
problemMessage: "Empty constructor bodies should be written using a ';' rather than '{}'."
correctionMessage: "Try replacing the constructor body with ';'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a constructor has an empty
block body.
#### Example
The following code produces this diagnostic because the constructor for
`C` has a block body that is empty:
```dart
class C {
C() [!{}!]
}
```
#### Common fixes
Replace the block with a semicolon:
```dart
class C {
C();
}
```
empty_statements:
problemMessage: "Unnecessary empty statement."
correctionMessage: "Try removing the empty statement or restructuring the code."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an empty statement is found.
#### Example
The following code produces this diagnostic because the statement
controlled by the `while` loop is an empty statement:
```dart
void f(bool condition) {
while (condition)[!;!]
g();
}
void g() {}
```
#### Common fixes
If there are no statements that need to be controlled, then remove both
the empty statement and the control structure it's part of (being careful
that any other code being removed doesn't have a side-effect that needs to
be preserved):
```dart
void f(bool condition) {
g();
}
void g() {}
```
If there are no statements that need to be controlled but the control
structure is still required for other reasons, then replace the empty
statement with a block to make the structure of the code more obvious:
```dart
void f(bool condition) {
while (condition) {}
g();
}
void g() {}
```
If there are statements that need to be controlled, remove the empty
statement and adjust the code so that the appropriate statements are being
controlled, possibly adding a block:
```dart
void f(bool condition) {
while (condition) {
g();
}
}
void g() {}
```
enable_null_safety:
removedIn: "3.0"
eol_at_end_of_file:
problemMessage: "Missing a newline at the end of the file."
correctionMessage: "Try adding a newline at the end of the file."
hasPublishedDocs: false
erase_dart_type_extension_types:
problemMessage: "Unsafe use of 'DartType' in an 'is' check."
correctionMessage: "Ensure DartType extension types are erased by using a helper method."
hasPublishedDocs: false
todo: |-
TODO(nshahan): Update.
exhaustive_cases:
problemMessage: "Missing case clauses for some constants in '{0}'."
correctionMessage: "Try adding case clauses for the missing constants."
hasPublishedDocs: false
file_names:
problemMessage: "The file name '{0}' isn't a lower_case_with_underscores identifier."
correctionMessage: "Try changing the name to follow the lower_case_with_underscores style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a `.dart` file
doesn't use lower_case_with_underscores.
#### Example
A file named `SliderMenu.dart` produces this diagnostic because the file
name uses the UpperCamelCase convention.
#### Common fixes
Rename the file to use the lower_case_with_underscores convention, such as
`slider_menu.dart`.
flutter_style_todos:
problemMessage: "To-do comment doesn't follow the Flutter style."
correctionMessage: "Try following the Flutter style for to-do comments."
hasPublishedDocs: false
hash_and_equals:
problemMessage: "Missing a corresponding override of '{0}'."
correctionMessage: "Try overriding '{0}' or removing '{1}'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a class or mixin either
overrides the definition of `==` but doesn't override the definition of
`hashCode`, or conversely overrides the definition of `hashCode` but
doesn't override the definition of `==`.
Both the `==` operator and the `hashCode` property of objects must be
consistent for a common hash map implementation to function properly. As a
result, when overriding either method, both should be overridden.
#### Example
The following code produces this diagnostic because the class `C`
overrides the `==` operator but doesn't override the getter `hashCode`:
```dart
class C {
final int value;
C(this.value);
@override
bool operator [!==!](Object other) =>
other is C &&
other.runtimeType == runtimeType &&
other.value == value;
}
```
#### Common fixes
If you need to override one of the members, then add an override of the
other:
```dart
class C {
final int value;
C(this.value);
@override
bool operator ==(Object other) =>
other is C &&
other.runtimeType == runtimeType &&
other.value == value;
@override
int get hashCode => value.hashCode;
}
```
If you don't need to override either of the members, then remove the
unnecessary override:
```dart
class C {
final int value;
C(this.value);
}
```
implementation_imports:
problemMessage: "Import of a library in the 'lib/src' directory of another package."
correctionMessage: "Try importing a public library that exports this library, or removing the import."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an import references a library
that's inside the `lib/src` directory of a different package, which
violates [the convention for pub
packages](https://dart.dev/tools/pub/package-layout#implementation-files).
#### Example
The following code, assuming that it isn't part of the `ffi` package,
produces this diagnostic because the library being imported is inside the
top-level `src` directory:
```dart
import [!'package:ffi/src/allocation.dart'!];
```
#### Common fixes
If the library being imported contains code that's part of the public API,
then import the public library that exports the public API:
```dart
import 'package:ffi/ffi.dart';
```
If the library being imported isn't part of the public API of the package,
then either find a different way to accomplish your goal, assuming that
it's possible, or open an issue asking the package authors to make it part
of the public API.
implicit_call_tearoffs:
problemMessage: "Implicit tear-off of the 'call' method."
correctionMessage: "Try explicitly tearing off the 'call' method."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an object with a `call` method
is assigned to a function-typed variable, implicitly tearing off the
`call` method.
#### Example
The following code produces this diagnostic because an instance of
`Callable` is passed to a function expecting a `Function`:
```dart
class Callable {
void call() {}
}
void callIt(void Function() f) {
f();
}
void f() {
callIt([!Callable()!]);
}
```
#### Common fixes
Explicitly tear off the `call` method:
```dart
class Callable {
void call() {}
}
void callIt(void Function() f) {
f();
}
void f() {
callIt(Callable().call);
}
```
implicit_reopen:
problemMessage: "The {0} '{1}' reopens '{2}' because it is not marked '{3}'."
correctionMessage: "Try marking '{1}' '{3}' or annotating it with '@reopen'."
hasPublishedDocs: false
invalid_case_patterns:
problemMessage: "This expression is not valid in a 'case' clause in Dart 3.0."
correctionMessage: "Try refactoring the expression to be valid in 3.0."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_dart_as_js:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Cast from '{0}' to '{1}' casts a Dart value to a JS interop type, which might not be platform-consistent."
correctionMessage: "Try using conversion methods from 'dart:js_interop' to convert between Dart types and JS interop types."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_dart_is_js:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Runtime check between '{0}' and '{1}' checks whether a Dart value is a JS interop type, which might not be platform-consistent."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_js_as_dart:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Cast from '{0}' to '{1}' casts a JS interop value to a Dart type, which might not be platform-consistent."
correctionMessage: "Try using conversion methods from 'dart:js_interop' to convert between JS interop types and Dart types."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_js_as_incompatible_js:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Cast from '{0}' to '{1}' casts a JS interop value to an incompatible JS interop type, which might not be platform-consistent."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_js_is_dart:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Runtime check between '{0}' and '{1}' checks whether a JS interop value is a Dart type, which might not be platform-consistent."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_js_is_inconsistent_js:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Runtime check between '{0}' and '{1}' involves a non-trivial runtime check between two JS interop types that might not be platform-consistent."
correctionMessage: "Try using a JS interop member like 'isA' from 'dart:js_interop' to check the underlying type of JS interop values."
hasPublishedDocs: false
invalid_runtime_check_with_js_interop_types_js_is_unrelated_js:
sharedName: invalid_runtime_check_with_js_interop_types
problemMessage: "Runtime check between '{0}' and '{1}' involves a runtime check between a JS interop value and an unrelated JS interop type that will always be true and won't check the underlying type."
correctionMessage: "Try using a JS interop member like 'isA' from 'dart:js_interop' to check the underlying type of JS interop values, or make the JS interop type a supertype using 'implements'."
hasPublishedDocs: false
invariant_booleans:
removedIn: "3.0"
iterable_contains_unrelated_type:
removedIn: "3.3"
join_return_with_assignment:
problemMessage: "Assignment could be inlined in 'return' statement."
correctionMessage: "Try inlining the assigned value in the 'return' statement."
hasPublishedDocs: false
leading_newlines_in_multiline_strings:
problemMessage: "Missing a newline at the beginning of a multiline string."
correctionMessage: "Try adding a newline at the beginning of the string."
hasPublishedDocs: false
library_annotations:
problemMessage: "This annotation should be attached to a library directive."
correctionMessage: "Try attaching the annotation to a library directive."
hasPublishedDocs: false
library_names:
problemMessage: "The library name '{0}' isn't a lower_case_with_underscores identifier."
correctionMessage: "Try changing the name to follow the lower_case_with_underscores style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a library doesn't
use the lower_case_with_underscores naming convention.
#### Example
The following code produces this diagnostic because the library name
`libraryName` isn't a lower_case_with_underscores identifier:
```dart
library [!libraryName!];
```
#### Common fixes
If the library name is not required, then remove the library name:
```dart
library;
```
If the library name is required, then convert it to use the
lower_case_with_underscores naming convention:
```dart
library library_name;
```
library_prefixes:
problemMessage: "The prefix '{0}' isn't a lower_case_with_underscores identifier."
correctionMessage: "Try changing the prefix to follow the lower_case_with_underscores style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an import prefix doesn't use
the lower_case_with_underscores naming convention.
#### Example
The following code produces this diagnostic because the prefix
`ffiSupport` isn't a lower_case_with_underscores identifier:
```dart
import 'package:ffi/ffi.dart' as [!ffiSupport!];
```
#### Common fixes
Convert the prefix to use the lower_case_with_underscores naming
convention:
```dart
import 'package:ffi/ffi.dart' as ffi_support;
```
library_private_types_in_public_api:
problemMessage: "Invalid use of a private type in a public API."
correctionMessage: "Try making the private type public, or making the API that uses the private type also be private."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a type that is not part of the
public API of a library is referenced in the public API of that library.
Using a private type in a public API can make the API unusable outside the
defining library.
#### Example
The following code produces this diagnostic because the parameter `c` of
the public function `f` has a type that is library private (`_C`):
```dart
void f([!_C!] c) {}
class _C {}
```
#### Common fixes
If the API doesn't need to be used outside the defining library, then make
it private:
```dart
void _f(_C c) {}
class _C {}
```
If the API needs to be part of the public API of the library, then either
use a different type that's public, or make the referenced type public:
```dart
void f(C c) {}
class C {}
```
lines_longer_than_80_chars:
problemMessage: "The line length exceeds the 80-character limit."
correctionMessage: "Try breaking the line across multiple lines."
hasPublishedDocs: false
list_remove_unrelated_type:
removedIn: "3.3"
literal_only_boolean_expressions:
problemMessage: "The Boolean expression has a constant value."
correctionMessage: "Try changing the expression."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the value of the condition in
an `if` or loop statement is known to be either always `true` or always
`false`. An exception is made for a `while` loop whose condition is the
Boolean literal `true`.
#### Examples
The following code produces this diagnostic because the condition will
always evaluate to `true`:
```dart
void f() {
[!if (true) {
print('true');
}!]
}
```
The lint will evaluate a subset of expressions that are composed of
constants, so the following code will also produce this diagnostic because
the condition will always evaluate to `false`:
```dart
void g(int i) {
[!if (1 == 0 || 3 > 4) {
print('false');
}!]
}
```
#### Common fixes
If the condition is wrong, then correct the condition so that it's value
can't be known at compile time:
```dart
void g(int i) {
if (i == 0 || i > 4) {
print('false');
}
}
```
If the condition is correct, then simplify the code to not evaluate the
condition:
```dart
void f() {
print('true');
}
```
matching_super_parameters:
problemMessage: "The super parameter named '{0}'' does not share the same name as the corresponding parameter in the super constructor, '{1}'."
correctionMessage: "Try using the name of the corresponding parameter in the super constructor."
hasPublishedDocs: false
missing_code_block_language_in_doc_comment:
problemMessage: "The code block is missing a specified language."
correctionMessage: "Try adding a language to the code block."
hasPublishedDocs: false
missing_whitespace_between_adjacent_strings:
problemMessage: "Missing whitespace between adjacent strings."
correctionMessage: "Try adding whitespace between the strings."
hasPublishedDocs: false
no_adjacent_strings_in_list:
problemMessage: "Don't use adjacent strings in a list literal."
correctionMessage: "Try adding a comma between the strings."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when two string literals are
adjacent in a list literal. Adjacent strings in Dart are concatenated
together to form a single string, but the intent might be for each string
to be a separate element in the list.
#### Example
The following code produces this diagnostic because the strings `'a'` and
`'b'` are adjacent:
```dart
List<String> list = [[!'a' 'b'!], 'c'];
```
#### Common fixes
If the two strings are intended to be separate elements of the list, then
add a comma between them:
```dart
List<String> list = ['a', 'b', 'c'];
```
If the two strings are intended to be a single concatenated string, then
either manually merge the strings:
```dart
List<String> list = ['ab', 'c'];
```
Or use the `+` operator to concatenate the strings:
```dart
List<String> list = ['a' + 'b', 'c'];
```
no_default_cases:
problemMessage: "Invalid use of 'default' member in a switch."
correctionMessage: "Try enumerating all the possible values of the switch expression."
hasPublishedDocs: false
no_duplicate_case_values:
problemMessage: "The value of the case clause ('{0}') is equal to the value of an earlier case clause ('{1}')."
correctionMessage: "Try removing or changing the value."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when two or more `case` clauses in
the same `switch` statement have the same value.
Any `case` clauses after the first can't be executed, so having duplicate
`case` clauses is misleading.
This diagnostic is often the result of either a typo or a change to the
value of a constant.
#### Example
The following code produces this diagnostic because two case clauses have
the same value (1):
```dart
// @dart = 2.14
void f(int v) {
switch (v) {
case 1:
break;
case [!1!]:
break;
}
}
```
#### Common fixes
If one of the clauses should have a different value, then change the value
of the clause:
```dart
void f(int v) {
switch (v) {
case 1:
break;
case 2:
break;
}
}
```
If the value is correct, then merge the statements into a single clause:
```dart
void f(int v) {
switch (v) {
case 1:
break;
}
}
```
no_leading_underscores_for_library_prefixes:
problemMessage: "The library prefix '{0}' starts with an underscore."
correctionMessage: "Try renaming the prefix to not start with an underscore."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a prefix declared
on an import starts with an underscore.
Library prefixes are inherently not visible outside the declaring library,
so a leading underscore indicating private adds no value.
#### Example
The following code produces this diagnostic because the prefix `_core`
starts with an underscore:
```dart
import 'dart:core' as [!_core!];
```
#### Common fixes
Remove the underscore:
```dart
import 'dart:core' as core;
```
no_leading_underscores_for_local_identifiers:
problemMessage: "The local variable '{0}' starts with an underscore."
correctionMessage: "Try renaming the variable to not start with an underscore."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a local variable
starts with an underscore.
Local variables are inherently not visible outside the declaring library,
so a leading underscore indicating private adds no value.
#### Example
The following code produces this diagnostic because the parameter `_s`
starts with an underscore:
```dart
int f(String [!_s!]) => _s.length;
```
#### Common fixes
Remove the underscore:
```dart
int f(String s) => s.length;
```
no_literal_bool_comparisons:
problemMessage: "Unnecessary comparison to a boolean literal."
correctionMessage: "Remove the comparison and use the negate `!` operator if necessary."
hasPublishedDocs: false
no_logic_in_create_state:
problemMessage: "Don't put any logic in 'createState'."
correctionMessage: "Try moving the logic out of 'createState'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an implementation of
`createState` in a subclass of `StatefulWidget` contains any logic other
than the return of the result of invoking a zero argument constructor.
#### Examples
The following code produces this diagnostic because the constructor
invocation has arguments:
```dart
import 'package:flutter/material.dart';
class MyWidget extends StatefulWidget {
@override
MyState createState() => [!MyState(0)!];
}
class MyState extends State {
int x;
MyState(this.x);
}
```
#### Common fixes
Rewrite the code so that `createState` doesn't contain any logic:
```dart
import 'package:flutter/material.dart';
class MyWidget extends StatefulWidget {
@override
MyState createState() => MyState();
}
class MyState extends State {
int x = 0;
MyState();
}
```
no_runtimeType_toString:
problemMessage: "Using 'toString' on a 'Type' is not safe in production code."
correctionMessage: "Try removing the usage of 'toString' or restructuring the code."
hasPublishedDocs: false
no_self_assignments:
problemMessage: "The variable or property is being assigned to itself."
correctionMessage: "Try removing the assignment that has no direct effect."
hasPublishedDocs: false
no_wildcard_variable_uses:
problemMessage: "The referenced identifier is a wildcard."
correctionMessage: "Use an identifier name that is not a wildcard."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when either a parameter or local
variable whose name consists of only underscores is referenced. Such
names will become non-binding in a future version of the Dart language,
making the reference illegal.
#### Example
The following code produces this diagnostic because the name of the
parameter consists of two underscores:
```dart
void f(int __) {
print([!__!]);
}
```
The following code produces this diagnostic because the name of the
local variable consists of a single underscore:
```dart
void f() {
int _ = 0;
print([!_!]);
}
```
#### Common fixes
If the variable or parameter is intended to be referenced, then give it a
name that has at least one non-underscore character:
```dart
void f(int p) {
print(p);
}
```
If the variable or parameter is not intended to be referenced, then
replace the reference with a different expression:
```dart
void f() {
print(0);
}
```
non_constant_identifier_names:
problemMessage: "The variable name '{0}' isn't a lowerCamelCase identifier."
correctionMessage: "Try changing the name to follow the lowerCamelCase style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a class member,
top-level declaration, variable, parameter, named parameter, or named
constructor that isn't declared to be `const`, doesn't use the
lowerCamelCase convention.
#### Example
The following code produces this diagnostic because the top-level variable
`Count` doesn't start with a lowercase letter:
```dart
var [!Count!] = 0;
```
#### Common fixes
Change the name in the declaration to follow the lowerCamelCase
convention:
```dart
var count = 0;
```
noop_primitive_operations:
problemMessage: "The expression has no effect and can be removed."
correctionMessage: "Try removing the expression."
hasPublishedDocs: false
null_check_on_nullable_type_parameter:
problemMessage: "The null check operator shouldn't be used on a variable whose type is a potentially nullable type parameter."
correctionMessage: "Try explicitly testing for 'null'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a null check operator is used
on a variable whose type is `T?`, where `T` is a type parameter that
allows the type argument to be nullable (either has no bound or has a
bound that is nullable).
Given a generic type parameter `T` which has a nullable bound, it is very
easy to introduce erroneous null checks when working with a variable of
type `T?`. Specifically, it is not uncommon to have `T? x;` and want to
assert that `x` has been set to a valid value of type `T`. A common
mistake is to do so using `x!`. This is almost always incorrect, because
if `T` is a nullable type, `x` may validly hold `null` as a value of type
`T`.
#### Example
The following code produces this diagnostic because `t` has the type `T?`
and `T` allows the type argument to be nullable (because it has no
`extends` clause):
```dart
T f<T>(T? t) => t[!!!];
```
#### Common fixes
Use the type parameter to cast the variable:
```dart
T f<T>(T? t) => t as T;
```
null_closures:
problemMessage: "Closure can't be 'null' because it might be invoked."
correctionMessage: "Try providing a non-null closure."
hasPublishedDocs: false
omit_local_variable_types:
problemMessage: "Unnecessary type annotation on a local variable."
correctionMessage: "Try removing the type annotation."
hasPublishedDocs: false
omit_obvious_local_variable_types:
problemMessage: "Omit the type annotation on a local variable when the type is obvious."
correctionMessage: "Try removing the type annotation."
hasPublishedDocs: false
one_member_abstracts:
problemMessage: "Unnecessary use of an abstract class."
correctionMessage: "Try making '{0}' a top-level function and removing the class."
hasPublishedDocs: false
only_throw_errors:
problemMessage: "Don't throw instances of classes that don't extend either 'Exception' or 'Error'."
correctionMessage: "Try throwing a different class of object."
hasPublishedDocs: false
overridden_fields:
problemMessage: "Field overrides a field inherited from '{0}'."
correctionMessage: "Try removing the field, overriding the getter and setter if necessary."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a class defines a field that
overrides a field from a superclass.
Overriding a field with another field causes the object to have two
distinct fields, but because the fields have the same name only one of the
fields can be referenced in a given scope. That can lead to confusion
where a reference to one of the fields can be mistaken for a reference to
the other.
#### Example
The following code produces this diagnostic because the field `f` in `B`
shadows the field `f` in `A`:
```dart
class A {
int f = 1;
}
class B extends A {
@override
int [!f!] = 2;
}
```
#### Common fixes
If the two fields are representing the same property, then remove the
field from the subclass:
```dart
class A {
int f = 1;
}
class B extends A {}
```
If the two fields should be distinct, then rename one of the fields:
```dart
class A {
int f = 1;
}
class B extends A {
int g = 2;
}
```
If the two fields are related in some way, but can't be the same, then
find a different way to implement the semantics you need.
package_api_docs:
problemMessage: "Missing documentation for public API."
correctionMessage: "Try adding a documentation comment."
hasPublishedDocs: false
package_names:
problemMessage: "The package name '{0}' isn't a lower_case_with_underscores identifier."
correctionMessage: "Try changing the name to follow the lower_case_with_underscores style."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the name of a package doesn't
use the lower_case_with_underscores naming convention.
#### Example
The following code produces this diagnostic because the name of the
package uses the lowerCamelCase naming convention:
```yaml
name: [!somePackage!]
```
#### Common fixes
Rewrite the name of the package using the lower_case_with_underscores
naming convention:
```yaml
name: some_package
```
package_prefixed_library_names:
problemMessage: "The library name is not a dot-separated path prefixed by the package name."
correctionMessage: "Try changing the name to '{0}'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a library has a name that
doesn't follow these guidelines:
- Prefix all library names with the package name.
- Make the entry library have the same name as the package.
- For all other libraries in a package, after the package name add the
dot-separated path to the library's Dart file.
- For libraries under `lib`, omit the top directory name.
For example, given a package named `my_package`, here are the library
names for various files in the package:
```dart
// In lib/my_package.dart
library my_package;
// In lib/other.dart
library my_package.other;
// In lib/foo/bar.dart
library my_package.foo.bar;
// In example/foo/bar.dart
library my_package.example.foo.bar;
// In lib/src/private.dart
library my_package.src.private;
```
#### Example
Assuming that the file containing the following code is not in a file
named `special.dart` in the `lib` directory of a package named `something`
(which would be an exception to the rule), the analyzer produces this
diagnostic because the name of the library doesn't conform to the
guidelines above:
```dart
library [!something.special!];
```
#### Common fixes
Change the name of the library to conform to the guidelines.
parameter_assignments:
problemMessage: "Invalid assignment to the parameter '{0}'."
correctionMessage: "Try using a local variable in place of the parameter."
hasPublishedDocs: false
prefer_adjacent_string_concatenation:
problemMessage: "String literals shouldn't be concatenated by the '+' operator."
correctionMessage: "Try removing the operator to use adjacent strings."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the `+` operator is used to
concatenate two string literals.
#### Example
The following code produces this diagnostic because two string literals
are being concatenated by using the `+` operator:
```dart
var s = 'a' [!+!] 'b';
```
#### Common fixes
Remove the operator:
```dart
var s = 'a' 'b';
```
prefer_asserts_in_initializer_lists:
problemMessage: "Assert should be in the initializer list."
correctionMessage: "Try moving the assert to the initializer list."
hasPublishedDocs: false
prefer_asserts_with_message:
problemMessage: "Missing a message in an assert."
correctionMessage: "Try adding a message to the assert."
hasPublishedDocs: false
prefer_bool_in_asserts:
removedIn: "3.0"
prefer_collection_literals:
problemMessage: "Unnecessary constructor invocation."
correctionMessage: "Try using a collection literal."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a constructor is used to create
a list, map, or set, but a literal would produce the same result.
#### Example
The following code produces this diagnostic because the constructor for
`Map` is being used to create a map that could also be created using a
literal:
```dart
var m = [!Map<String, String>()!];
```
#### Common fixes
Use the literal representation:
```dart
var m = <String, String>{};
```
prefer_conditional_assignment:
problemMessage: "The 'if' statement could be replaced by a null-aware assignment."
correctionMessage: "Try using the '??=' operator to conditionally assign a value."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an assignment to a variable is
conditional based on whether the variable has the value `null` and the
`??=` operator could be used instead.
#### Example
The following code produces this diagnostic because the parameter `s` is
being compared to `null` in order to determine whether to assign a
different value:
```dart
int f(String? s) {
[!if (s == null) {
s = '';
}!]
return s.length;
}
```
#### Common fixes
Use the `??=` operator instead of an explicit `if` statement:
```dart
int f(String? s) {
s ??= '';
return s.length;
}
```
prefer_const_constructors:
problemMessage: "Use 'const' with the constructor to improve performance."
correctionMessage: "Try adding the 'const' keyword to the constructor invocation."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an invocation of a const
constructor isn't either preceded by `const` or in a [constant context][].
#### Example
The following code produces this diagnostic because the invocation of the
`const` constructor is neither prefixed by `const` nor in a
[constant context][]:
```dart
class C {
const C();
}
C c = [!C()!];
```
#### Common fixes
If the context can be made a [constant context][], then do so:
```dart
class C {
const C();
}
const C c = C();
```
If the context can't be made a [constant context][], then add `const`
before the constructor invocation:
```dart
class C {
const C();
}
C c = const C();
```
prefer_const_constructors_in_immutables:
problemMessage: "Constructors in '@immutable' classes should be declared as 'const'."
correctionMessage: "Try adding 'const' to the constructor declaration."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a non-`const` constructor is
found in a class that has the `@immutable` annotation.
#### Example
The following code produces this diagnostic because the constructor in `C`
isn't declared as `const` even though `C` has the `@immutable` annotation:
```dart
import 'package:meta/meta.dart';
@immutable
class C {
final f;
[!C!](this.f);
}
```
#### Common fixes
If the class really is intended to be immutable, then add the `const`
modifier to the constructor:
```dart
import 'package:meta/meta.dart';
@immutable
class C {
final f;
const C(this.f);
}
```
If the class is mutable, then remove the `@immutable` annotation:
```dart
class C {
final f;
C(this.f);
}
```
prefer_const_declarations:
problemMessage: "Use 'const' for final variables initialized to a constant value."
correctionMessage: "Try replacing 'final' with 'const'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a top-level variable, static
field, or local variable is marked as `final` and is initialized to a
constant value.
#### Examples
The following code produces this diagnostic because the top-level variable
`v` is both `final` and initialized to a constant value:
```dart
[!final v = const <int>[]!];
```
The following code produces this diagnostic because the static field `f`
is both `final` and initialized to a constant value:
```dart
class C {
static [!final f = const <int>[]!];
}
```
The following code produces this diagnostic because the local variable `v`
is both `final` and initialized to a constant value:
```dart
void f() {
[!final v = const <int>[]!];
print(v);
}
```
#### Common fixes
Replace the keyword `final` with `const` and remove `const` from the
initializer:
```dart
class C {
static const f = <int>[];
}
```
prefer_const_literals_to_create_immutables:
problemMessage: "Use 'const' literals as arguments to constructors of '@immutable' classes."
correctionMessage: "Try adding 'const' before the literal."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a non-const list, map, or set
literal is passed as an argument to a constructor declared in a class
annotated with `@immutable`.
#### Example
The following code produces this diagnostic because the list literal
(`[1]`) is being passed to a constructor in an immutable class but isn't
a constant list:
```dart
import 'package:meta/meta.dart';
@immutable
class C {
final f;
const C(this.f);
}
C c = C([![1]!]);
```
#### Common fixes
If the context can be made a [constant context][], then do so:
```dart
import 'package:meta/meta.dart';
@immutable
class C {
final f;
const C(this.f);
}
const C c = C([1]);
```
If the context can't be made a [constant context][] but the constructor
can be invoked using `const`, then add `const` before the constructor
invocation:
```dart
import 'package:meta/meta.dart';
@immutable
class C {
final f;
const C(this.f);
}
C c = const C([1]);
```
If the context can't be made a [constant context][] and the constructor
can't be invoked using `const`, then add the keyword `const` before the
collection literal:
```dart
import 'package:meta/meta.dart';
@immutable
class C {
final f;
const C(this.f);
}
C c = C(const [1]);
```
prefer_constructors_over_static_methods:
problemMessage: "Static method should be a constructor."
correctionMessage: "Try converting the method into a constructor."
hasPublishedDocs: false
prefer_contains_always_false:
sharedName: prefer_contains
problemMessage: "Always 'false' because 'indexOf' is always greater than or equal to -1."
hasPublishedDocs: false
todo: |-
TODO(brianwilkerson): Should be warning rather than lint,
as represents a bug rather than style preference.
prefer_contains_always_true:
sharedName: prefer_contains
problemMessage: "Always 'true' because 'indexOf' is always greater than or equal to -1."
hasPublishedDocs: false
todo: |-
TODO(brianwilkerson): Should be warning rather than lint,
as represents a bug rather than style preference.
prefer_contains_use_contains:
sharedName: prefer_contains
problemMessage: "Unnecessary use of 'indexOf' to test for containment."
correctionMessage: "Try using 'contains'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the method `indexOf` is used and
the result is only compared with `-1` or `0` in a way where the semantics
are equivalent to using `contains`.
#### Example
The following code produces this diagnostic because the condition in the
`if` statement is checking to see whether the list contains the string:
```dart
void f(List<String> l, String s) {
if ([!l.indexOf(s) < 0!]) {
// ...
}
}
```
#### Common fixes
Use `contains` instead, negating the condition when necessary:
```dart
void f(List<String> l, String s) {
if (l.contains(s)) {
// ...
}
}
```
prefer_double_quotes:
problemMessage: "Unnecessary use of single quotes."
correctionMessage: "Try using double quotes unless the string contains double quotes."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a string literal uses single
quotes (`'`) when it could use double quotes (`"`) without needing extra
escapes and without hurting readability.
#### Example
The following code produces this diagnostic because the string literal
uses single quotes but doesn't need to:
```dart
void f(String name) {
print([!'Hello $name'!]);
}
```
#### Common fixes
Use double quotes in place of single quotes:
```dart
void f(String name) {
print("Hello $name");
}
```
prefer_equal_for_default_values:
removedIn: "3.0"
prefer_expression_function_bodies:
problemMessage: "Unnecessary use of a block function body."
correctionMessage: "Try using an expression function body."
hasPublishedDocs: false
prefer_final_fields:
problemMessage: "The private field {0} could be 'final'."
correctionMessage: "Try making the field 'final'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a private field is only
assigned one time. The field can be initialized in multiple constructors
and still be flagged because only one of those constructors can ever run.
#### Example
The following code produces this diagnostic because the field `_f` is only
assigned one time, in the field's initializer:
```dart
class C {
int [!_f = 1!];
int get f => _f;
}
```
#### Common fixes
Mark the field `final`:
```dart
class C {
final int _f = 1;
int get f => _f;
}
```
prefer_final_in_for_each_pattern:
sharedName: prefer_final_in_for_each
problemMessage: "The pattern should be final."
correctionMessage: "Try making the pattern final."
hasPublishedDocs: false
prefer_final_in_for_each_variable:
sharedName: prefer_final_in_for_each
problemMessage: "The variable '{0}' should be final."
correctionMessage: "Try making the variable final."
hasPublishedDocs: false
prefer_final_locals:
problemMessage: "Local variables should be final."
correctionMessage: "Try making the variable final."
hasPublishedDocs: false
prefer_final_parameters:
problemMessage: "The parameter '{0}' should be final."
correctionMessage: "Try making the parameter final."
hasPublishedDocs: false
prefer_for_elements_to_map_fromIterable:
problemMessage: "Use 'for' elements when building maps from iterables."
correctionMessage: "Try using a collection literal with a 'for' element."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when `Map.fromIterable` is used to
build a map that could be built using the `for` element.
#### Example
The following code produces this diagnostic because `fromIterable` is
being used to build a map that could be built using a `for` element:
```dart
void f(Iterable<String> data) {
[!Map<String, int>.fromIterable(
data,
key: (element) => element,
value: (element) => element.length,
)!];
}
```
#### Common fixes
Use a `for` element to build the map:
```dart
void f(Iterable<String> data) {
<String, int>{
for (var element in data)
element: element.length
};
}
```
prefer_foreach:
problemMessage: "Use 'forEach' rather than a 'for' loop to apply a function to every element."
correctionMessage: "Try using 'forEach' rather than a 'for' loop."
hasPublishedDocs: false
prefer_function_declarations_over_variables:
problemMessage: "Use a function declaration rather than a variable assignment to bind a function to a name."
correctionMessage: "Try rewriting the closure assignment as a function declaration."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a closure is assigned to a
local variable and the local variable is not re-assigned anywhere.
#### Example
The following code produces this diagnostic because the local variable `f`
is initialized to be a closure and isn't assigned any other value:
```dart
void g() {
var [!f = (int i) => i * 2!];
f(1);
}
```
#### Common fixes
Replace the local variable with a local function:
```dart
void g() {
int f(int i) => i * 2;
f(1);
}
```
prefer_generic_function_type_aliases:
problemMessage: "Use the generic function type syntax in 'typedef's."
correctionMessage: "Try using the generic function type syntax ('{0}')."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a typedef is written using the
older syntax for function type aliases in which the name being declared is
embedded in the function type.
#### Example
The following code produces this diagnostic because it uses the older
syntax:
```dart
typedef void [!F!]<T>();
```
#### Common fixes
Rewrite the typedef to use the newer syntax:
```dart
typedef F<T> = void Function();
```
prefer_if_elements_to_conditional_expressions:
problemMessage: "Use an 'if' element to conditionally add elements."
correctionMessage: "Try using an 'if' element rather than a conditional expression."
hasPublishedDocs: false
prefer_if_null_operators:
problemMessage: "Use the '??' operator rather than '?:' when testing for 'null'."
correctionMessage: "Try rewriting the code to use '??'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a conditional expression (using
the `?:` operator) is used to select a different value when a local
variable is `null`.
#### Example
The following code produces this diagnostic because the variable `s` is
being compared to `null` so that a different value can be returned when
`s` is `null`:
```dart
String f(String? s) => [!s == null ? '' : s!];
```
#### Common fixes
Use the if-null operator instead:
```dart
String f(String? s) => s ?? '';
```
prefer_initializing_formals:
problemMessage: "Use an initializing formal to assign a parameter to a field."
correctionMessage: "Try using an initialing formal ('this.{0}') to initialize the field."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a constructor parameter is used
to initialize a field without modification.
#### Example
The following code produces this diagnostic because the parameter `c` is
only used to set the field `c`:
```dart
class C {
int c;
C(int c) : [!this.c = c!];
}
```
#### Common fixes
Use an initializing formal parameter to initialize the field:
```dart
class C {
int c;
C(this.c);
}
```
prefer_inlined_adds_single:
sharedName: prefer_inlined_adds
problemMessage: "The addition of a list item could be inlined."
correctionMessage: "Try adding the item to the list literal directly."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the methods `add` and `addAll`
are invoked on a list literal where the elements being added could be
included in the list literal.
#### Example
The following code produces this diagnostic because the `add` method is
being used to add `b`, when it could have been included directly in the
list literal:
```dart
List<String> f(String a, String b) {
return [a]..[!add!](b);
}
```
The following code produces this diagnostic because the `addAll` method is
being used to add the elements of `b`, when it could have been included
directly in the list literal:
```dart
List<String> f(String a, List<String> b) {
return [a]..[!addAll!](b);
}
```
#### Common fixes
If the `add` method is being used, then make the argument an element of
the list and remove the invocation:
```dart
List<String> f(String a, String b) {
return [a, b];
}
```
If the `addAll` method is being used, then use the spread operator on the
argument to add its elements to the list and remove the invocation:
```dart
List<String> f(String a, List<String> b) {
return [a, ...b];
}
```
prefer_inlined_adds_multiple:
sharedName: prefer_inlined_adds
problemMessage: "The addition of multiple list items could be inlined."
correctionMessage: "Try adding the items to the list literal directly."
hasPublishedDocs: true
prefer_int_literals:
problemMessage: "Unnecessary use of a 'double' literal."
correctionMessage: "Try using an 'int' literal."
hasPublishedDocs: false
prefer_interpolation_to_compose_strings:
problemMessage: "Use interpolation to compose strings and values."
correctionMessage: "Try using string interpolation to build the composite string."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when string literals and computed
strings are being concatenated using the `+` operator, but string
interpolation would achieve the same result.
#### Example
The following code produces this diagnostic because the elements of the
list `l` are being concatenated with other strings using the `+` operator:
```dart
String f(List<String> l) {
return [!'(' + l[0] + ', ' + l[1] + ')'!];
}
```
#### Common fixes
Use string interpolation:
```dart
String f(List<String> l) {
return '(${l[0]}, ${l[1]})';
}
```
prefer_is_empty_always_false:
sharedName: prefer_is_empty
problemMessage: "The comparison is always 'false' because the length is always greater than or equal to 0."
hasPublishedDocs: false
todo: |-
TODO(brianwilkerson): Should be warning rather than lint,
as represents a bug rather than style preference.
prefer_is_empty_always_true:
sharedName: prefer_is_empty
problemMessage: "The comparison is always 'true' because the length is always greater than or equal to 0."
hasPublishedDocs: false
todo: |-
TODO(brianwilkerson): Should be warning rather than lint,
as represents a bug rather than style preference.
prefer_is_empty_use_is_empty:
sharedName: prefer_is_empty
problemMessage: "Use 'isEmpty' instead of 'length' to test whether the collection is empty."
correctionMessage: "Try rewriting the expression to use 'isEmpty'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the result of invoking either
`Iterable.length` or `Map.length` is compared for equality with zero
(`0`).
#### Example
The following code produces this diagnostic because the result of invoking
`length` is checked for equality with zero:
```dart
int f(Iterable<int> p) => [!p.length == 0!] ? 0 : p.first;
```
#### Common fixes
Replace the use of `length` with a use of either `isEmpty` or
`isNotEmpty`:
```dart
void f(Iterable<int> p) => p.isEmpty ? 0 : p.first;
```
prefer_is_empty_use_is_not_empty:
sharedName: prefer_is_empty
problemMessage: "Use 'isNotEmpty' instead of 'length' to test whether the collection is empty."
correctionMessage: "Try rewriting the expression to use 'isNotEmpty'."
hasPublishedDocs: true
prefer_is_not_empty:
problemMessage: "Use 'isNotEmpty' rather than negating the result of 'isEmpty'."
correctionMessage: "Try rewriting the expression to use 'isNotEmpty'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the result of invoking
`Iterable.isEmpty` or `Map.isEmpty` is negated.
#### Example
The following code produces this diagnostic because the result of invoking
`Iterable.isEmpty` is negated:
```dart
void f(Iterable<int> p) => [!!p.isEmpty!] ? p.first : 0;
```
#### Common fixes
Rewrite the code to use `isNotEmpty`:
```dart
void f(Iterable<int> p) => p.isNotEmpty ? p.first : 0;
```
prefer_is_not_operator:
problemMessage: "Use the 'is!' operator rather than negating the value of the 'is' operator."
correctionMessage: "Try rewriting the condition to use the 'is!' operator."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the prefix `!` operator is used
to negate the result of an `is` test.
#### Example
The following code produces this diagnostic because the result of testing
to see whether `o` is a `String` is negated using the prefix `!` operator:
```dart
String f(Object o) {
if ([!!(o is String)!]) {
return o.toString();
}
return o;
}
```
#### Common fixes
Use the `is!` operator instead:
```dart
String f(Object o) {
if (o is! String) {
return o.toString();
}
return o;
}
```
prefer_iterable_whereType:
problemMessage: "Use 'whereType' to select elements of a given type."
correctionMessage: "Try rewriting the expression to use 'whereType'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the method `Iterable.where` is
being used to filter elements based on their type.
#### Example
The following code produces this diagnostic because the method `where` is
being used to access only the strings within the iterable:
```dart
Iterable<Object> f(Iterable<Object> p) => p.[!where!]((e) => e is String);
```
#### Common fixes
Rewrite the code to use `whereType`:
```dart
Iterable<String> f(Iterable<Object> p) => p.whereType<String>();
```
This might also allow you to tighten the types in your code or remove
other type checks.
prefer_mixin:
problemMessage: "Only mixins should be mixed in."
correctionMessage: "Try converting '{0}' to a mixin."
hasPublishedDocs: false
prefer_null_aware_method_calls:
problemMessage: "Use a null-aware invocation of the 'call' method rather than explicitly testing for 'null'."
correctionMessage: "Try using '?.call()' to invoke the function."
hasPublishedDocs: false
prefer_null_aware_operators:
problemMessage: "Use the null-aware operator '?.' rather than an explicit 'null' comparison."
correctionMessage: "Try using '?.'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a comparison with `null` is
used to guard a member reference, and `null` is used as a result when the
guarded target is `null`.
#### Example
The following code produces this diagnostic because the invocation of
`length` is guarded by a `null` comparison even though the default value
is `null`:
```dart
int? f(List<int>? p) {
return [!p == null ? null : p.length!];
}
```
#### Common fixes
Use a null-aware access operator instead:
```dart
int? f(List<int>? p) {
return p?.length;
}
```
prefer_relative_imports:
problemMessage: "Use relative imports for files in the 'lib' directory."
correctionMessage: "Try converting the URI to a relative URI."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an `import` in a library inside
the `lib` directory uses a `package:` URI to refer to another library in
the same package.
#### Example
The following code produces this diagnostic because it uses a `package:`
URI when a relative URI could have been used:
```dart
import 'package:my_package/bar.dart';
```
#### Common fixes
Use a relative URI to import the library:
```dart
import 'bar.dart';
```
prefer_single_quotes:
problemMessage: "Unnecessary use of double quotes."
correctionMessage: "Try using single quotes unless the string contains single quotes."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a string literal uses double
quotes (`"`) when it could use single quotes (`'`) without needing extra
escapes and without hurting readability.
#### Example
The following code produces this diagnostic because the string literal
uses double quotes but doesn't need to:
```dart
void f(String name) {
print([!"Hello $name"!]);
}
```
#### Common fixes
Use single quotes in place of double quotes:
```dart
void f(String name) {
print('Hello $name');
}
```
prefer_spread_collections:
problemMessage: "The addition of multiple elements could be inlined."
correctionMessage: "Try using the spread operator ('...') to inline the addition."
hasPublishedDocs: false
prefer_typing_uninitialized_variables_for_field:
sharedName: prefer_typing_uninitialized_variables
problemMessage: "An uninitialized field should have an explicit type annotation."
correctionMessage: "Try adding a type annotation."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a variable without an
initializer doesn't have an explicit type annotation.
Without either a type annotation or an initializer, a variable has the
type `dynamic`, which allows any value to be assigned to the variable,
often causing hard to identify bugs.
#### Example
The following code produces this diagnostic because the variable `r`
doesn't have either a type annotation or an initializer:
```dart
Object f() {
var [!r!];
r = '';
return r;
}
```
#### Common fixes
If the variable can be initialized, then add an initializer:
```dart
Object f() {
var r = '';
return r;
}
```
If the variable can't be initialized, then add an explicit type
annotation:
```dart
Object f() {
String r;
r = '';
return r;
}
```
prefer_typing_uninitialized_variables_for_local_variable:
sharedName: prefer_typing_uninitialized_variables
problemMessage: "An uninitialized variable should have an explicit type annotation."
correctionMessage: "Try adding a type annotation."
hasPublishedDocs: true
prefer_void_to_null:
problemMessage: "Unnecessary use of the type 'Null'."
correctionMessage: "Try using 'void' instead."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when `Null` is used in a location
where `void` would be a valid choice.
#### Example
The following code produces this diagnostic because the function `f` is
declared to return `null` (at some future time):
```dart
Future<[!Null!]> f() async {}
```
#### Common fixes
Replace the use of `Null` with a use of `void`:
```dart
Future<void> f() async {}
```
provide_deprecation_message:
problemMessage: "Missing a deprecation message."
correctionMessage: "Try using the constructor to provide a message ('@Deprecated(\"message\")')."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a `deprecated` annotation is
used instead of the `Deprecated` annotation.
#### Example
The following code produces this diagnostic because the function `f` is
annotated with `deprecated`:
```dart
[!@deprecated!]
void f() {}
```
#### Common fixes
Convert the code to use the longer form:
```dart
@Deprecated('Use g instead. Will be removed in 4.0.0.')
void f() {}
```
public_member_api_docs:
problemMessage: "Missing documentation for a public member."
correctionMessage: "Try adding documentation for the member."
hasPublishedDocs: false
recursive_getters:
problemMessage: "The getter '{0}' recursively returns itself."
correctionMessage: "Try changing the value being returned."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a getter invokes itself,
resulting in an infinite loop.
#### Example
The following code produces this diagnostic because the getter `count`
invokes itself:
```dart
class C {
int _count = 0;
int get [!count!] => count;
}
```
#### Common fixes
Change the getter to not invoke itself:
```dart
class C {
int _count = 0;
int get count => _count;
}
```
require_trailing_commas:
problemMessage: "Missing a required trailing comma."
correctionMessage: "Try adding a trailing comma."
hasPublishedDocs: false
secure_pubspec_urls:
problemMessage: "The '{0}' protocol shouldn't be used because it isn't secure."
correctionMessage: "Try using a secure protocol, such as 'https'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a URL in a `pubspec.yaml` file is
using a non-secure scheme, such as `http`.
#### Example
The following code produces this diagnostic because the `pubspec.yaml` file
contains an `http` URL:
```yaml
dependencies:
example: any
repository: [!http://github.com/dart-lang/example!]
```
#### Common fixes
Change the scheme of the URL to use a secure scheme, such as `https`:
```yaml
dependencies:
example: any
repository: https://github.com/dart-lang/example
```
sized_box_for_whitespace:
problemMessage: "Use a 'SizedBox' to add whitespace to a layout."
correctionMessage: "Try using a 'SizedBox' rather than a 'Container'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a `Container` is created using
only the `height` and/or `width` arguments.
#### Example
The following code produces this diagnostic because the `Container` has
only the `width` argument:
```dart
import 'package:flutter/material.dart';
Widget buildRow() {
return Row(
children: <Widget>[
const Text('...'),
[!Container!](
width: 4,
child: Text('...'),
),
const Expanded(
child: Text('...'),
),
],
);
}
```
#### Common fixes
Replace the `Container` with a `SizedBox` of the same dimensions:
```dart
import 'package:flutter/material.dart';
Widget buildRow() {
return Row(
children: <Widget>[
Text('...'),
SizedBox(
width: 4,
child: Text('...'),
),
Expanded(
child: Text('...'),
),
],
);
}
```
sized_box_shrink_expand:
problemMessage: "Use 'SizedBox.{0}' to avoid needing to specify the 'height' and 'width'."
correctionMessage: "Try using 'SizedBox.{0}' and removing the 'height' and 'width' arguments."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a `SizedBox` constructor
invocation specifies the values of both `height` and `width` as either
`0.0` or `double.infinity`.
#### Examples
The following code produces this diagnostic because both the `height` and
`width` are `0.0`:
```dart
import 'package:flutter/material.dart';
Widget build() {
return [!SizedBox!](
height: 0.0,
width: 0.0,
child: const Text(''),
);
}
```
The following code produces this diagnostic because both the `height` and
`width` are `double.infinity`:
```dart
import 'package:flutter/material.dart';
Widget build() {
return [!SizedBox!](
height: double.infinity,
width: double.infinity,
child: const Text(''),
);
}
```
#### Common fixes
If both are `0.0`, then use `SizedBox.shrink`:
```dart
import 'package:flutter/material.dart';
Widget build() {
return SizedBox.shrink(
child: const Text(''),
);
}
```
If both are `double.infinity`, then use `SizedBox.expand`:
```dart
import 'package:flutter/material.dart';
Widget build() {
return SizedBox.expand(
child: const Text(''),
);
}
```
slash_for_doc_comments:
problemMessage: "Use the end-of-line form ('///') for doc comments."
correctionMessage: "Try rewriting the comment to use '///'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a documentation comment uses
the block comment style (delimited by `/**` and `*/`).
#### Example
The following code produces this diagnostic because the documentation
comment for `f` uses a block comment style:
```dart
[!/**
* Example.
*/!]
void f() {}
```
#### Common fixes
Use an end-of-line comment style:
```dart
/// Example.
void f() {}
```
sort_child_properties_last:
problemMessage: "The '{0}' argument should be last in widget constructor invocations."
correctionMessage: "Try moving the argument to the end of the argument list."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the `child` or `children`
argument isn't the last argument in an invocation of a widget class'
constructor. An exception is made if all of the arguments after the
`child` or `children` argument are function expressions.
#### Example
The following code produces this diagnostic because the `child` argument
isn't the last argument in the invocation of the `Center` constructor:
```dart
import 'package:flutter/material.dart';
Widget createWidget() {
return Center(
[!child: Text('...')!],
widthFactor: 0.5,
);
}
```
#### Common fixes
Move the `child` or `children` argument to be last:
```dart
import 'package:flutter/material.dart';
Widget createWidget() {
return Center(
widthFactor: 0.5,
child: Text('...'),
);
}
```
sort_constructors_first:
problemMessage: "Constructor declarations should be before non-constructor declarations."
correctionMessage: "Try moving the constructor declaration before all other members."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a constructor declaration is
preceded by one or more non-constructor declarations.
#### Example
The following code produces this diagnostic because the constructor for
`C` appears after the method `m`:
```dart
class C {
void m() {}
[!C!]();
}
```
#### Common fixes
Move all of the constructor declarations before any other declarations:
```dart
class C {
C();
void m() {}
}
```
sort_pub_dependencies:
problemMessage: "Dependencies not sorted alphabetically."
correctionMessage: "Try sorting the dependencies alphabetically (A to Z)."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the keys in a dependency map in
the `pubspec.yaml` file aren't sorted alphabetically. The dependency maps
that are checked are the `dependencies`, `dev_dependencies`, and
`dependency_overrides` maps.
#### Example
The following code produces this diagnostic because the entries in the
`dependencies` map are not sorted:
```yaml
dependencies:
path: any
collection: any
```
#### Common fixes
Sort the entries:
```yaml
dependencies:
collection: any
path: any
```
sort_unnamed_constructors_first:
problemMessage: "Invalid location for the unnamed constructor."
correctionMessage: "Try moving the unnamed constructor before all other constructors."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when an unnamed constructor appears
after a named constructor.
#### Example
The following code produces this diagnostic because the unnamed
constructor is after the named constructor:
```dart
class C {
C.named();
[!C!]();
}
```
#### Common fixes
Move the unnamed constructor before any other constructors:
```dart
class C {
C();
C.named();
}
```
specify_nonobvious_local_variable_types:
problemMessage: "Specify the type of a local variable when the type is non-obvious."
correctionMessage: "Try adding a type annotation."
super_goes_last:
removedIn: "3.0"
test_types_in_equals:
problemMessage: "Missing type test for '{0}' in '=='."
correctionMessage: "Try testing the type of '{0}'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an override of the `==`
operator doesn't include a type test on the value of the parameter.
#### Example
The following code produces this diagnostic because `other` is not type
tested:
```dart
class C {
final int f;
C(this.f);
@override
bool operator ==(Object other) {
return ([!other as C!]).f == f;
}
}
```
#### Common fixes
Perform an `is` test as part of computing the return value:
```dart
class C {
final int f;
C(this.f);
@override
bool operator ==(Object other) {
return other is C && other.f == f;
}
}
```
throw_in_finally:
problemMessage: "Use of '{0}' in 'finally' block."
correctionMessage: "Try moving the '{0}' outside the 'finally' block."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a `throw` statement is found
inside a `finally` block.
#### Example
The following code produces this diagnostic because there is a `throw`
statement inside a `finally` block:
```dart
void f() {
try {
// ...
} catch (e) {
// ...
} finally {
[!throw 'error'!];
}
}
```
#### Common fixes
Rewrite the code so that the `throw` statement isn't inside a `finally`
block:
```dart
void f() {
try {
// ...
} catch (e) {
// ...
}
throw 'error';
}
```
tighten_type_of_initializing_formals:
problemMessage: "Use a type annotation rather than 'assert' to enforce non-nullability."
correctionMessage: "Try adding a type annotation and removing the 'assert'."
hasPublishedDocs: false
type_annotate_public_apis:
problemMessage: "Missing type annotation on a public API."
correctionMessage: "Try adding a type annotation."
hasPublishedDocs: false
type_init_formals:
problemMessage: "Don't needlessly type annotate initializing formals."
correctionMessage: "Try removing the type."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an initializing formal
parameter (`this.x`) or a super parameter (`super.x`) has an explicit type
annotation that is the same as the field or overridden parameter.
If a constructor parameter is using `this.x` to initialize a field, then
the type of the parameter is implicitly the same type as the field. If a
constructor parameter is using `super.x` to forward to a super
constructor, then the type of the parameter is implicitly the same as the
super constructor parameter.
#### Example
The following code produces this diagnostic because the parameter `this.c`
has an explicit type that is the same as the field `c`:
```dart
class C {
int c;
C([!int!] this.c);
}
```
The following code produces this diagnostic because the parameter
`super.a` has an explicit type that is the same as the parameter `a` from
the superclass:
```dart
class A {
A(int a);
}
class B extends A {
B([!int!] super.a);
}
```
#### Common fixes
Remove the type annotation from the parameter:
```dart
class C {
int c;
C(this.c);
}
```
type_literal_in_constant_pattern:
problemMessage: "Use 'TypeName _' instead of a type literal."
correctionMessage: "Replace with 'TypeName _'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a type literal appears as a
pattern.
#### Example
The following code produces this diagnostic because a type literal is used
as a constant pattern:
```dart
void f(Object? x) {
if (x case [!num!]) {
// ...
}
}
```
#### Common fixes
If the type literal is intended to match an object of the given type, then
use either a variable pattern:
```dart
void f(Object? x) {
if (x case num _) {
// ...
}
}
```
Or an object pattern:
```dart
void f(Object? x) {
if (x case num()) {
// ...
}
}
```
If the type literal is intended to match the type literal, then write it
as a constant pattern:
```dart
void f(Object? x) {
if (x case const (num)) {
// ...
}
}
```
unawaited_futures:
problemMessage: "Missing an 'await' for the 'Future' computed by this expression."
correctionMessage: "Try adding an 'await' or wrapping the expression with 'unawaited'."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when an instance of `Future` is
returned from an invocation within an `async` (or `async*`) method or
function and the future is neither awaited nor passed to the `unawaited`
function.
#### Example
The following code produces this diagnostic because the function `g`
returns a future, but the future isn't awaited:
```dart
Future<void> f() async {
[!g();!]
}
Future<int> g() => Future.value(0);
```
#### Common fixes
If the future needs to complete before the following code is executed,
then add an `await` before the invocation:
```dart
Future<void> f() async {
await g();
}
Future<int> g() => Future.value(0);
```
If the future doesn't need to complete before the following code is
executed, then wrap the `Future`-returning invocation in an invocation of
the `unawaited` function:
```dart
import 'dart:async';
Future<void> f() async {
unawaited(g());
}
Future<int> g() => Future.value(0);
```
unintended_html_in_doc_comment:
problemMessage: "Angle brackets will be interpreted as HTML."
correctionMessage: "Try using backticks around the content with angle brackets, or try replacing `<` with `&lt;` and `>` with `&gt;`."
hasPublishedDocs: false
unnecessary_await_in_return:
problemMessage: "Unnecessary 'await'."
correctionMessage: "Try removing the 'await'."
hasPublishedDocs: false
unnecessary_brace_in_string_interps:
problemMessage: "Unnecessary braces in a string interpolation."
correctionMessage: "Try removing the braces."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a string interpolation with
braces is used to interpolate a simple identifier and isn't followed by
alphanumeric text.
#### Example
The following code produces this diagnostic because the interpolation
element `${s}` uses braces when they are not necessary:
```dart
String f(String s) {
return '"[!${s}!]"';
}
```
#### Common fixes
Remove the unnecessary braces:
```dart
String f(String s) {
return '"$s"';
}
```
unnecessary_breaks:
problemMessage: "Unnecessary 'break' statement."
correctionMessage: "Try removing the 'break'."
hasPublishedDocs: false
unnecessary_const:
problemMessage: "Unnecessary 'const' keyword."
correctionMessage: "Try removing the keyword."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the keyword `const` is used in
a [constant context][]. The keyword isn't required because it's implied.
#### Example
The following code produces this diagnostic because the keyword `const` in
the list literal isn't needed:
```dart
const l = [!const!] <int>[];
```
The list is implicitly `const` because of the keyword `const` on the
variable declaration.
#### Common fixes
Remove the unnecessary keyword:
```dart
const l = <int>[];
```
unnecessary_constructor_name:
problemMessage: "Unnecessary '.new' constructor name."
correctionMessage: "Try removing the '.new'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a reference to an unnamed
constructor uses `.new`. The only place where `.new` is required is in a
constructor tear-off.
#### Example
The following code produces this diagnostic because `.new` is being used
to refer to the unnamed constructor where it isn't required:
```dart
var o = Object.[!new!]();
```
#### Common fixes
Remove the unnecessary `.new`:
```dart
var o = Object();
```
unnecessary_final_with_type:
sharedName: unnecessary_final
problemMessage: "Local variables should not be marked as 'final'."
correctionMessage: "Remove the 'final'."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a local variable is marked as
being `final`.
#### Example
The following code produces this diagnostic because the local variable `c`
is marked as being `final`:
```dart
void f(int a, int b) {
[!final!] c = a + b;
print(c);
}
```
#### Common fixes
If the variable doesn't have a type annotation, then replace the `final`
with `var`:
```dart
void f(int a, int b) {
var c = a + b;
print(c);
}
```
If the variable has a type annotation, then remove the `final`
modifier:
```dart
void f(int a, int b) {
int c = a + b;
print(c);
}
```
unnecessary_final_without_type:
sharedName: unnecessary_final
problemMessage: "Local variables should not be marked as 'final'."
correctionMessage: "Replace 'final' with 'var'."
hasPublishedDocs: false
unnecessary_getters_setters:
problemMessage: "Unnecessary use of getter and setter to wrap a field."
correctionMessage: "Try removing the getter and setter and renaming the field."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a getter and setter pair
returns and sets the value of a field without any additional processing.
#### Example
The following code produces this diagnostic because the getter/setter pair
named `c` only expose the field named `_c`:
```dart
class C {
int? _c;
int? get [!c!] => _c;
set c(int? v) => _c = v;
}
```
#### Common fixes
Make the field public and remove the getter and setter:
```dart
class C {
int? c;
}
```
unnecessary_lambdas:
problemMessage: "Closure should be a tearoff."
correctionMessage: "Try using a tearoff rather than a closure."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a closure (lambda) could be
replaced by a tear-off.
#### Example
The following code produces this diagnostic because the closure passed to
`forEach` contains only an invocation of the function `print` with the
parameter of the closure:
```dart
void f(List<String> strings) {
strings.forEach([!(string) {
print(string);
}!]);
}
```
#### Common fixes
Replace the closure with a tear-off of the function or method being
invoked with the closure:
```dart
void f(List<String> strings) {
strings.forEach(print);
}
```
unnecessary_late:
problemMessage: "Unnecessary 'late' modifier."
correctionMessage: "Try removing the 'late'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a top-level variable or static
field with an initializer is marked as `late`. Top-level variables and
static fields are implicitly late, so they don't need to be explicitly
marked.
#### Example
The following code produces this diagnostic because the static field `c`
has the modifier `late` even though it has an initializer:
```dart
class C {
static [!late!] String c = '';
}
```
#### Common fixes
Remove the keyword `late`:
```dart
class C {
static String c = '';
}
```
unnecessary_library_directive:
problemMessage: "Library directives without comments or annotations should be avoided."
correctionMessage: "Try deleting the library directive."
hasPublishedDocs: false
unnecessary_library_name:
problemMessage: "Library names are not necessary."
correctionMessage: "Remove the library name."
hasPublishedDocs: false
unnecessary_new:
problemMessage: "Unnecessary 'new' keyword."
correctionMessage: "Try removing the 'new' keyword."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the keyword `new` is used to
invoke a constructor.
#### Example
The following code produces this diagnostic because the keyword `new` is
used to invoke the unnamed constructor from `Object`:
```dart
var o = [!new!] Object();
```
#### Common fixes
Remove the keyword `new`:
```dart
var o = Object();
```
unnecessary_null_aware_assignments:
problemMessage: "Unnecessary assignment of 'null'."
correctionMessage: "Try removing the assignment."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the right-hand side of a
null-aware assignment is the `null` literal.
#### Example
The following code produces this diagnostic because the null aware
operator is being used to assign `null` to `s` when `s` is already `null`:
```dart
void f(String? s) {
[!s ??= null!];
}
```
#### Common fixes
If a non-null value should be assigned to the left-hand operand, then
change the right-hand side:
```dart
void f(String? s) {
s ??= '';
}
```
If there is no non-null value to assign to the left-hand operand, then
remove the assignment:
```dart
void f(String? s) {
}
```
unnecessary_null_aware_operator_on_extension_on_nullable:
problemMessage: "Unnecessary use of a null-aware operator to invoke an extension method on a nullable type."
correctionMessage: "Try removing the '?'."
hasPublishedDocs: false
unnecessary_null_checks:
problemMessage: "Unnecessary use of a null check ('!')."
correctionMessage: "Try removing the null check."
hasPublishedDocs: false
unnecessary_null_in_if_null_operators:
problemMessage: "Unnecessary use of '??' with 'null'."
correctionMessage: "Try removing the '??' operator and the 'null' operand."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the right operand of the `??`
operator is the literal `null`.
#### Example
The following code produces this diagnostic because the right-hand operand
of the `??` operator is `null`:
```dart
String? f(String? s) => s ?? [!null!];
```
#### Common fixes
If a non-null value should be used for the right-hand operand, then
change the right-hand side:
```dart
String f(String? s) => s ?? '';
```
If there is no non-null value to use for the right-hand operand, then
remove the operator and the right-hand operand:
```dart
String? f(String? s) => s;
```
unnecessary_nullable_for_final_variable_declarations:
problemMessage: "Type could be non-nullable."
correctionMessage: "Try changing the type to be non-nullable."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a final field or variable has a
nullable type but is initialized to a non-nullable value.
#### Example
The following code produces this diagnostic because the final variable `i`
has a nullable type (`int?`), but can never be `null`:
```dart
final int? [!i!] = 1;
```
#### Common fixes
Make the type non-nullable:
```dart
final int i = 1;
```
unnecessary_overrides:
problemMessage: "Unnecessary override."
correctionMessage: "Try adding behavior in the overriding member or removing the override."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an instance member overrides an
inherited member but only invokes the overridden member with exactly the
same arguments.
#### Example
The following code produces this diagnostic because the method `D.m`
doesn't do anything other than invoke the overridden method:
```dart
class C {
int m(int x) => x;
}
class D extends C {
@override
int [!m!](int x) => super.m(x);
}
```
#### Common fixes
If the method should do something more than what the overridden method
does, then implement the missing functionality:
```dart
class C {
int m(int x) => x;
}
class D extends C {
@override
int m(int x) => super.m(x) + 1;
}
```
If the overridden method should be modified by changing the return type or
one or more of the parameter types, making one of the parameters
`covariant`, having a documentation comment, or by having additional
annotations, then update the code:
```dart
import 'package:meta/meta.dart';
class C {
int m(int x) => x;
}
class D extends C {
@mustCallSuper
@override
int m(int x) => super.m(x);
}
```
If the overriding method doesn't change or enhance the semantics of the
code, then remove it:
```dart
class C {
int m(int x) => x;
}
class D extends C {}
```
unnecessary_parenthesis:
problemMessage: "Unnecessary use of parentheses."
correctionMessage: "Try removing the parentheses."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when parentheses are used where they
do not affect the semantics of the code.
#### Example
The following code produces this diagnostic because the parentheses around
the binary expression are not necessary:
```dart
int f(int a, int b) => [!(a + b)!];
```
#### Common fixes
Remove the unnecessary parentheses:
```dart
int f(int a, int b) => a + b;
```
unnecessary_raw_strings:
problemMessage: "Unnecessary use of a raw string."
correctionMessage: "Try using a normal string."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a string literal is marked as
being raw (is prefixed with an `r`), but making the string raw doesn't
change the value of the string.
#### Example
The following code produces this diagnostic because the string literal
will have the same value without the `r` as it does with the `r`:
```dart
var s = [!r'abc'!];
```
#### Common fixes
Remove the `r` in front of the string literal:
```dart
var s = 'abc';
```
unnecessary_statements:
problemMessage: "Unnecessary statement."
correctionMessage: "Try completing the statement or breaking it up."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when an expression statement has no
clear effect.
#### Example
The following code produces this diagnostic because the addition of the
returned values from the two invocations has no clear effect:
```dart
void f(int Function() first, int Function() second) {
[!first() + second()!];
}
```
#### Common fixes
If the expression doesn't need to be computed, then remove it:
```dart
void f(int Function() first, int Function() second) {
}
```
If the value of the expression is needed, then make use of it, possibly
assigning it to a local variable first:
```dart
void f(int Function() first, int Function() second) {
print(first() + second());
}
```
If portions of the expression need to be executed, then remove the
unnecessary portions:
```dart
void f(int Function() first, int Function() second) {
first();
second();
}
```
unnecessary_string_escapes:
problemMessage: "Unnecessary escape in string literal."
correctionMessage: "Remove the '\\' escape."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when characters in a string are
escaped when escaping them is unnecessary.
#### Example
The following code produces this diagnostic because single quotes don't
need to be escaped inside strings delimited by double quotes:
```dart
var s = "Don[!\!]'t use a backslash here.";
```
#### Common fixes
Remove the unnecessary backslashes:
```dart
var s = "Don't use a backslash here.";
```
unnecessary_string_interpolations:
problemMessage: "Unnecessary use of string interpolation."
correctionMessage: "Try replacing the string literal with the variable name."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a string literal contains a
single interpolation of a `String`-valued variable and no other
characters.
#### Example
The following code produces this diagnostic because the string literal
contains a single interpolation and doesn't contain any character outside
the interpolation:
```dart
String f(String s) => [!'$s'!];
```
#### Common fixes
Replace the string literal with the content of the interpolation:
```dart
String f(String s) => s;
```
unnecessary_this:
problemMessage: "Unnecessary 'this.' qualifier."
correctionMessage: "Try removing 'this.'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the keyword `this` is used to
access a member that isn't shadowed.
#### Example
The following code produces this diagnostic because the use of `this` to
access the field `_f` isn't necessary:
```dart
class C {
int _f = 2;
int get f => [!this!]._f;
}
```
#### Common fixes
Remove the `this.`:
```dart
class C {
int _f = 2;
int get f => _f;
}
```
unnecessary_to_list_in_spreads:
problemMessage: "Unnecessary use of 'toList' in a spread."
correctionMessage: "Try removing the invocation of 'toList'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when `toList` is used to convert an
`Iterable` to a `List` just before a spread operator is applied to the
list. The spread operator can be applied to any `Iterable`, so the
conversion isn't necessary.
#### Example
The following code produces this diagnostic because `toList` is invoked on
the result of `map`, which is an `Iterable` that the spread operator could
be applied to directly:
```dart
List<String> toLowercase(List<String> strings) {
return [
...strings.map((String s) => s.toLowerCase()).[!toList!](),
];
}
```
#### Common fixes
Remove the invocation of `toList`:
```dart
List<String> toLowercase(List<String> strings) {
return [
...strings.map((String s) => s.toLowerCase()),
];
}
```
unreachable_from_main:
problemMessage: "Unreachable member '{0}' in an executable library."
correctionMessage: "Try referencing the member or removing it."
hasPublishedDocs: false
unrelated_type_equality_checks_in_expression:
sharedName: unrelated_type_equality_checks
problemMessage: "The type of the right operand ('{0}') isn't a subtype or a supertype of the left operand ('{1}')."
correctionMessage: "Try changing one or both of the operands."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when two objects are being compared
and neither of the static types of the two objects is a subtype of the
other.
Such a comparison will usually return `false` and might not reflect the
programmer's intent.
There can be false positives. For example, a class named `Point` might
have subclasses named `CartesianPoint` and `PolarPoint`, neither of which
is a subtype of the other, but it might still be appropriate to test the
equality of instances.
As a concrete case, the classes `Int64` and `Int32` from `package:fixnum`
allow comparing instances to an `int` provided the `int` is on the
right-hand side. This case is specifically allowed by the diagnostic, but
other such cases are not.
#### Example
The following code produces this diagnostic because the string `s` is
being compared to the integer `1`:
```dart
bool f(String s) {
return s [!==!] 1;
}
```
#### Common fixes
Replace one of the operands with something compatible with the other
operand:
```dart
bool f(String s) {
return s.length == 1;
}
```
unrelated_type_equality_checks_in_pattern:
sharedName: unrelated_type_equality_checks
problemMessage: "The type of the operand ('{0}') isn't a subtype or a supertype of the value being matched ('{1}')."
correctionMessage: "Try changing one or both of the operands."
hasPublishedDocs: true
unsafe_html_attribute:
sharedName: unsafe_html
problemMessage: "Assigning to the attribute '{0}' is unsafe."
correctionMessage: "Try finding a different way to implement the page."
hasPublishedDocs: false
unsafe_html_method:
sharedName: unsafe_html
problemMessage: "Invoking the method '{0}' is unsafe."
correctionMessage: "Try finding a different way to implement the page."
hasPublishedDocs: false
unsafe_html_constructor:
sharedName: unsafe_html
problemMessage: "Invoking the constructor '{0}' is unsafe."
correctionMessage: "Try finding a different way to implement the page."
hasPublishedDocs: false
use_build_context_synchronously_async_use:
sharedName: use_build_context_synchronously
problemMessage: "Don't use 'BuildContext's across async gaps."
correctionMessage: "Try rewriting the code to not use the 'BuildContext', or guard the use with a 'mounted' check."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a `BuildContext` is referenced
by a `StatefulWidget` after an asynchronous gap without first checking the
`mounted` property.
Storing a `BuildContext` for later use can lead to difficult to diagnose
crashes. Asynchronous gaps implicitly store a `BuildContext`, making them
easy to overlook for diagnosis.
#### Example
The following code produces this diagnostic because the `context` is
passed to a constructor after the `await`:
```dart
import 'package:flutter/material.dart';
class MyWidget extends Widget {
void onButtonTapped(BuildContext context) async {
await Future.delayed(const Duration(seconds: 1));
Navigator.of([!context!]).pop();
}
}
```
#### Common fixes
If you can remove the asynchronous gap, do so:
```dart
import 'package:flutter/material.dart';
class MyWidget extends Widget {
void onButtonTapped(BuildContext context) {
Navigator.of(context).pop();
}
}
```
If you can't remove the asynchronous gap, then use `mounted` to guard the
use of the `context`:
```dart
import 'package:flutter/material.dart';
class MyWidget extends Widget {
void onButtonTapped(BuildContext context) async {
await Future.delayed(const Duration(seconds: 1));
if (context.mounted) {
Navigator.of(context).pop();
}
}
}
```
use_colored_box:
problemMessage: "Use a 'ColoredBox' rather than a 'Container' with only a 'Color'."
correctionMessage: "Try replacing the 'Container' with a 'ColoredBox'."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a `Container` is created that
only sets the color.
#### Example
The following code produces this diagnostic because the only attribute of
the container that is set is the `color`:
```dart
import 'package:flutter/material.dart';
Widget build() {
return [!Container!](
color: Colors.red,
child: const Text('hello'),
);
}
```
#### Common fixes
Replace the `Container` with a `ColoredBox`:
```dart
import 'package:flutter/material.dart';
Widget build() {
return ColoredBox(
color: Colors.red,
child: const Text('hello'),
);
}
```
use_decorated_box:
problemMessage: "Use 'DecoratedBox' rather than a 'Container' with only a 'Decoration'."
correctionMessage: "Try replacing the 'Container' with a 'DecoratedBox'."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a `Container` is created that
only sets the decoration.
#### Example
The following code produces this diagnostic because the only attribute of
the container that is set is the `decoration`:
```dart
import 'package:flutter/material.dart';
Widget buildArea() {
return [!Container!](
decoration: const BoxDecoration(
color: Colors.red,
borderRadius: BorderRadius.all(
Radius.circular(5),
),
),
child: const Text('...'),
);
}
```
#### Common fixes
Replace the `Container` with a `DecoratedBox`:
```dart
import 'package:flutter/material.dart';
Widget buildArea() {
return DecoratedBox(
decoration: const BoxDecoration(
color: Colors.red,
borderRadius: BorderRadius.all(
Radius.circular(5),
),
),
child: const Text('...'),
);
}
```
use_build_context_synchronously_wrong_mounted:
sharedName: use_build_context_synchronously
problemMessage: "Don't use 'BuildContext's across async gaps, guarded by an unrelated 'mounted' check."
correctionMessage: "Guard a 'State.context' use with a 'mounted' check on the State, and other BuildContext use with a 'mounted' check on the BuildContext."
hasPublishedDocs: true
use_enums:
problemMessage: "Class should be an enum."
correctionMessage: "Try using an enum rather than a class."
hasPublishedDocs: false
use_full_hex_values_for_flutter_colors:
problemMessage: "Instances of 'Color' should be created using an 8-digit hexadecimal integer (such as '0xFFFFFFFF')."
correctionMessage: "Try using an 8-digit hexadecimal integer to create the 'Color'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the argument to the constructor
of the `Color` class is a literal integer that isn't represented as an
8-digit hexadecimal integer.
#### Example
The following code produces this diagnostic because the argument (`1`)
isn't represented as an 8-digit hexadecimal integer:
```dart
import 'package:flutter/material.dart';
Color c = Color([!1!]);
```
#### Common fixes
Convert the representation to be an 8-digit hexadecimal integer:
```dart
import 'package:flutter/material.dart';
Color c = Color(0x00000001);
```
use_function_type_syntax_for_parameters:
problemMessage: "Use the generic function type syntax to declare the parameter '{0}'."
correctionMessage: "Try using the generic function type syntax."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the older style function-valued
parameter syntax is used.
#### Example
The following code produces this diagnostic because the function-valued
parameter `f` is declared using an older style syntax:
```dart
void g([!bool f(String s)!]) {}
```
#### Common fixes
Use the generic function type syntax to declare the parameter:
```dart
void g(bool Function(String) f) {}
```
use_if_null_to_convert_nulls_to_bools:
problemMessage: "Use an if-null operator to convert a 'null' to a 'bool'."
correctionMessage: "Try using an if-null operator."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a nullable `bool`-valued
expression is compared (using `==` or `!=`) to a boolean literal.
#### Example
The following code produces this diagnostic because the nullable boolean
variable `b` is compared to `true`:
```dart
void f(bool? b) {
if ([!b == true!]) {
// Treats `null` as `false`.
}
}
```
#### Common fixes
Rewrite the condition to use `??` instead:
```dart
void f(bool? b) {
if (b ?? false) {
// Treats `null` as `false`.
}
}
```
use_is_even_rather_than_modulo:
problemMessage: "Use '{0}' rather than '% 2'."
correctionMessage: "Try using '{0}'."
hasPublishedDocs: false
use_key_in_widget_constructors:
problemMessage: "Constructors for public widgets should have a named 'key' parameter."
correctionMessage: "Try adding a named parameter to the constructor."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a constructor in a subclass of
`Widget` that isn't private to its library doesn't have a parameter named
`key`.
#### Example
The following code produces this diagnostic because the constructor for
the class `MyWidget` doesn't have a parameter named `key`:
```dart
import 'package:flutter/material.dart';
class MyWidget extends StatelessWidget {
[!MyWidget!]({required int height});
}
```
The following code produces this diagnostic because the default
constructor for the class `MyWidget` doesn't have a parameter named `key`:
```dart
import 'package:flutter/material.dart';
class [!MyWidget!] extends StatelessWidget {}
```
#### Common fixes
Add a parameter named `key` to the constructor, explicitly declaring the
constructor if necessary:
```dart
import 'package:flutter/material.dart';
class MyWidget extends StatelessWidget {
MyWidget({super.key, required int height});
}
```
use_late_for_private_fields_and_variables:
problemMessage: "Use 'late' for private members with a non-nullable type."
correctionMessage: "Try making adding the modifier 'late'."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a private field or variable is
marked as being nullable, but every reference assumes that the variable is
never `null`.
#### Example
The following code produces this diagnostic because the private top-level
variable `_i` is nullable, but every reference assumes that it will not be
`null`:
```dart
void f() {
_i!.abs();
}
int? [!_i!];
```
#### Common fixes
Mark the variable or field as being both non-nullable and `late` to
indicate that it will always be assigned a non-null:
```dart
void f() {
_i.abs();
}
late int _i;
```
use_named_constants:
problemMessage: "Use the constant '{0}' rather than a constructor returning the same object."
correctionMessage: "Try using '{0}'."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a constant is created with the
same value as a known `const` variable.
#### Example
The following code produces this diagnostic because there is a known
`const` field (`Duration.zero`) whose value is the same as what the
constructor invocation will evaluate to:
```dart
Duration d = [!const Duration(seconds: 0)!];
```
#### Common fixes
Replace the constructor invocation with a reference to the known `const`
variable:
```dart
Duration d = Duration.zero;
```
use_raw_strings:
problemMessage: "Use a raw string to avoid using escapes."
correctionMessage: "Try making the string a raw string and removing the escapes."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a string literal containing
escapes, and no interpolations, could be marked as being raw in order to
avoid the need for the escapes.
#### Example
The following code produces this diagnostic because the string contains
escaped characters that wouldn't need to be escaped if the string is
made a raw string:
```dart
var s = [!'A string with only \\ and \$'!];
```
#### Common fixes
Mark the string as being raw and remove the unnecessary backslashes:
```dart
var s = r'A string with only \ and $';
```
use_rethrow_when_possible:
problemMessage: "Use 'rethrow' to rethrow a caught exception."
correctionMessage: "Try replacing the 'throw' with a 'rethrow'."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a caught exception is thrown
using a `throw` expression rather than a `rethrow` statement.
#### Example
The following code produces this diagnostic because the caught exception
`e` is thrown using a `throw` expression:
```dart
void f() {
try {
// ...
} catch (e) {
[!throw e!];
}
}
```
#### Common fixes
Use `rethrow` instead of `throw`:
```dart
void f() {
try {
// ...
} catch (e) {
rethrow;
}
}
```
use_setters_to_change_properties:
problemMessage: "The method is used to change a property."
correctionMessage: "Try converting the method to a setter."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when a method is used to set the
value of a field, or a function is used to set the value of a top-level
variable, and nothing else.
#### Example
The following code produces this diagnostic because the method `setF` is
used to set the value of the field `_f` and does no other work:
```dart
class C {
int _f = 0;
void [!setF!](int value) => _f = value;
}
```
#### Common fixes
Convert the method to a setter:
```dart
class C {
int _f = 0;
set f(int value) => _f = value;
}
```
use_string_buffers:
problemMessage: "Use a string buffer rather than '+' to compose strings."
correctionMessage: "Try writing the parts of a string to a string buffer."
hasPublishedDocs: false
documentation: |-
#### Description
The analyzer produces this diagnostic when values are concatenated to a
string inside a loop without using a `StringBuffer` to do the
concatenation.
#### Example
The following code produces this diagnostic because the string `result` is
computed by repeated concatenation within the `for` loop:
```dart
String f() {
var result = '';
for (int i = 0; i < 10; i++) {
[!result += 'a'!];
}
return result;
}
```
#### Common fixes
Use a `StringBuffer` to compute the result:
```dart
String f() {
var buffer = StringBuffer();
for (int i = 0; i < 10; i++) {
buffer.write('a');
}
return buffer.toString();
}
```
use_string_in_part_of_directives:
problemMessage: "The part-of directive uses a library name."
correctionMessage: "Try converting the directive to use the URI of the library."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a `part of` directive uses a
library name to refer to the library that the part is a part of.
#### Example
Given a file named `lib.dart` that contains the following:
```dart
%uri="lib/lib.dart"
library lib;
part 'test.dart';
```
The following code produces this diagnostic because the `part of`
directive uses the name of the library rather than the URI of the library
it's part of:
```dart
[!part of lib;!]
```
#### Common fixes
Use a URI to reference the library:
```dart
part of 'lib.dart';
```
use_super_parameters_multiple:
sharedName: use_super_parameters
problemMessage: "Parameters '{0}' could be super parameters."
correctionMessage: "Trying converting '{0}' to super parameters."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a parameter to a constructor is
passed to a super constructor without being referenced or modified and a
`super` parameter isn't used.
#### Example
The following code produces this diagnostic because the parameters of the
constructor for `B` are only used as arguments to the super constructor:
```dart
class A {
A({int? x, int? y});
}
class B extends A {
[!B!]({int? x, int? y}) : super(x: x, y: y);
}
```
#### Common fixes
Use a `super` parameter to pass the arguments:
```dart
class A {
A({int? x, int? y});
}
class B extends A {
B({super.x, super.y});
}
```
use_super_parameters_single:
sharedName: use_super_parameters
problemMessage: "Parameter '{0}' could be a super parameter."
correctionMessage: "Trying converting '{0}' to a super parameter."
hasPublishedDocs: true
use_test_throws_matchers:
problemMessage: "Use the 'throwsA' matcher instead of using 'fail' when there is no exception thrown."
correctionMessage: "Try removing the try-catch and using 'throwsA' to expect an exception."
hasPublishedDocs: false
use_to_and_as_if_applicable:
problemMessage: "Start the name of the method with 'to' or 'as'."
correctionMessage: "Try renaming the method to use either 'to' or 'as'."
hasPublishedDocs: false
use_truncating_division:
problemMessage: "Use truncating division."
correctionMessage: "Try using truncating division, '~/', instead of regular division ('/') followed by 'toInt()'."
hasPublishedDocs: false
valid_regexps:
problemMessage: "Invalid regular expression syntax."
correctionMessage: "Try correcting the regular expression."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when the string passed to the
default constructor of the class `RegExp` doesn't contain a valid regular
expression.
A regular expression created with invalid syntax will throw a
`FormatException` at runtime.
#### Example
The following code produces this diagnostic because the regular expression
isn't valid:
```dart
var r = RegExp([!r'('!]);
```
#### Common fixes
Fix the regular expression:
```dart
var r = RegExp(r'\(');
```
void_checks:
problemMessage: "Assignment to a variable of type 'void'."
correctionMessage: "Try removing the assignment or changing the type of the variable."
hasPublishedDocs: true
documentation: |-
#### Description
The analyzer produces this diagnostic when a value is assigned to a
variable of type `void`.
It isn't possible to access the value of such a variable, so the
assignment has no value.
#### Example
The following code produces this diagnostic because the field `value` has
the type `void`, but a value is being assigned to it:
```dart
class A<T> {
T? value;
}
void f(A<void> a) {
[!a.value = 1!];
}
```
The following code produces this diagnostic because the type of the
parameter `p` in the method `m` is `void`, but a value is being assigned
to it in the invocation:
```dart
class A<T> {
void m(T p) { }
}
void f(A<void> a) {
a.m([!1!]);
}
```
#### Common fixes
If the type of the variable is incorrect, then change the type of the
variable:
```dart
class A<T> {
T? value;
}
void f(A<int> a) {
a.value = 1;
}
```
If the type of the variable is correct, then remove the assignment:
```dart
class A<T> {
T? value;
}
void f(A<void> a) {}
```