The Dart Linter package defines lint rules that identify and report on "lints" found in Dart code. Linting is performed by the Dart
analysis server and the dart analyze
command in the Dart command-line tool.
The linter is bundled with the Dart SDK; if you have an updated Dart SDK already, you're done!
Alternatively, if you want to contribute to the linter or examine the source, clone the linter
repo like this:
$ git clone https://github.com/dart-lang/linter.git
The linter gives you feedback to help you catch potential errors and keep your code in line with the published
Dart Style Guide. Enforceable lint rules (or "lints") are catalogued here and can be configured via an
analysis options file. The linter is run from within the dart analyze
command-line tool shipped with the
Dart SDK. Assuming you have lints configured in an analysis_options.yaml
file at the root of your project with these contents:
linter:
rules:
- annotate_overrides
- hash_and_equals
- prefer_is_not_empty
you could lint your package like this:
$ dart analyze .
and see any violations of the annotate_overrides
, hash_and_equals
, and prefer_is_not_empty
rules in the console. To help you choose
the rules you want to enable for your package, we have provided a complete list of rules. For the lints that are enforced
internally at Google, see package:pedantic
. For a set of rules corresponding to the
Effective Dart guide, see package:effective_dart
.
If a specific lint warning should be ignored, it can be flagged with a comment. For example,
// ignore: camel_case_types
class whyOhWhy { }
tells the Dart analyzer to ignore this instance of the camel_case_types
warning.
End-of-line comments are supported as well. The following communicates the same thing:
class whyOhWhy { // ignore: camel_case_types
To ignore a rule for an entire file, use the ignore_for_file
comment flag. For example,
// ignore_for_file: camel_case_types
...
class whyOhWhy { }
tells the Dart analyzer to ignore all occurrences of the camel_case_types
warning in this file.
As lints are treated the same as errors and warnings by the analyzer, their severity can similarly be configured in an options file. For example, an analysis options file that specifies
linter:
rules:
- camel_case_types
analyzer:
errors:
camel_case_types: error
tells the analyzer to treat camel_case_types
lints as errors. For more on configuring analysis see the analysis option file docs.
Feedback is greatly appreciated and contributions are welcome! Please read the contribution guidelines; mechanics of writing lints are covered here.
Please file feature requests and bugs in the issue tracker.