Skip to content

Presets

Presets are cumulative starting points. Each level includes every rule from the levels before it, then adds a clearly defined kind of scrutiny. Choose the lowest tier whose philosophy matches the project and override individual rules when the codebase deliberately makes a different choice.

Preset Total rules Adds Intended use
none 0 0 Explicit opt-out or a fully hand-picked rule set.
core 35 35 Near-certain defects with almost no stylistic judgement.
recommended 97 62 The default choice for most production projects.
opinionated 184 87 A coherent Many Lints house style.
pedantic 241 57 Maximum uniformity, explicitness, ordering, and structural limits.

none is the default and enables no rules. It is useful while evaluating the plugin, for repositories that enable every rule individually, and for a shared configuration that should provide options without selecting a policy tier.

many_lints.yaml
preset: none

Use core when diagnostics must have an exceptionally high signal-to-noise ratio. It targets contradictory conditions, invalid type relationships, unreachable behavior, broken lifecycle management, and other code that is very likely to fail independently of the team’s preferred style.

recommended includes core and adds likely defects, concrete runtime risks, and broadly accepted Dart and Flutter practices. It avoids naming schemes, architecture mandates, dependency-specific preferences, and choices on which healthy codebases commonly disagree. This is the best starting point for most applications and packages.

opinionated includes recommended and chooses a side where several valid styles exist. It prefers particular widget shapes, collection expressions, control-flow forms, shorthand syntax, and type-annotation habits. Adopt it when consistency is worth occasionally disabling a preference that does not fit the project.

pedantic includes opinionated and treats mechanical consistency as a goal in its own right. It adds strict naming, one-declaration-per-file organization, file/type matching, constructor-first member order, alphabetical parameter and field order, complexity budgets, explicit callback parameter names, and a full ban on postfix ! including map[key]!.

Use it for codebases that want one predictable shape everywhere and accept configuration work during adoption. Because a plugin cannot activate Dart SDK lints, combine it with SDK rules such as always_specify_types, directives_ordering, and public_member_api_docs for the full strict style. Avoid pairing member_ordering with sort_constructors_first: their constructor-first checks overlap.

Some rules need project-specific vocabulary, assume an optional dependency, enforce the opposite of a convention selected by opinionated, or are deliberately opt-in conventions. They remain available by name so presets never guess package dependencies, silently do nothing without required options, overreach into project-specific taste, or enable fixes that undo one another.

Moving upward only adds rules: core ⊂ recommended ⊂ opinionated ⊂ pedantic. An explicit per-rule enabled: value always wins, so a project can adopt a tier and document its few intentional exceptions:

many_lints.yaml
preset: pedantic
rules:
avoid_long_functions:
max_lines: 80
prefer_spacing:
enabled: false
use_gap:
enabled: true

See Configuration for option precedence, per-rule exclusions, diagnostic severity, and both supported config locations.