Static Analysis, Linting and Formatting

Analyzer plugins (Dart 3.9+ support for custom lint rules) and custom_lint let you write your own rules (e.g., riverpod_lint).

Ignore a lint locally: // ignore: avoid_print or // ignore_for_file: lint_name.

# analysis_options.yaml
include: package:lints/recommended.yaml      # or package:flutter_lints/flutter.yaml, very_good_analysis

analyzer:
  language:
    strict-casts: true
    strict-inference: true
    strict-raw-types: true
  errors:
    unused_import: error
    missing_return: error
  exclude:
    - "**/*.g.dart"
    - "**/*.freezed.dart"

linter:
  rules:
    - prefer_const_constructors
    - prefer_final_locals
    - avoid_print
    - unawaited_futures
    - always_declare_return_types
    - require_trailing_commas
    - use_super_parameters
dart analyze                     # errors, warnings, lints
dart analyze --fatal-infos       # fail CI on infos too
dart fix --dry-run               # preview automated fixes
dart fix --apply
dart format .                    # canonical formatting (the "tall style" formatter in Dart 3.7+)
dart format --output=none --set-exit-if-changed .   # CI check

Why bother

The analyzer finds whole classes of bugs before the program runs: unused imports, futures that are never awaited (unawaited_futures), implicit dynamic that turns off type checking, and code that can never run. The strict-* language options in the example make it refuse silent type loosening, so a typo cannot quietly become dynamic.

dart format removes arguments about style entirely: everyone's code looks the same, so code reviews focus on behaviour. The usual setup runs both in CI, with dart analyze --fatal-infos and dart format --set-exit-if-changed, so a pull request cannot be merged with new warnings or unformatted code.

Common mistakes

Silencing a lint with // ignore: instead of fixing it, until ignores hide real problems. Ignore only with a reason in a comment.

Turning on every available rule at once on an existing project: thousands of warnings get ignored. Start from a recommended set and add rules gradually.

Forgetting to exclude generated files (*.g.dart), which then flood the report with warnings you cannot fix.

Related on EngiLipi