Use case

Hi Kate / @Piinks

First off, thank you for the recent work updating the style guide in #181985 and the lint modernization in #179089. These are great improvements for the Flutter community. I wanted to flag a minor point of clarification that might help reduce confusion for contributors.

While contributing to the repo, I noticed that the "Avoid using var and dynamic" section of the style guide (lines 799-808) appears to have not been updated alongside those lint changes, and now gives guidance that conflicts with the linter. (Apologies if there is already work in progress on this — I searched existing issues and open PRs but couldn't find it tracked anywhere.)

The style guide currently states (lines 799-803):

All variables and arguments are typed; avoid dynamic or Object in
any case where you could figure out the actual type. Always specialize
generic types where possible. Explicitly type all list and map
literals. Give types to all parameters, even in closures and even if you
don't use the parameter.

However, the repo's analysis_options.yaml now has:

• always_specify_types disabled (line 43)
• omit_obvious_local_variable_types enabled (line 148)
• specify_nonobvious_local_variable_types enabled (line 207)

This creates a situation where:

1. The style guide says "All variables ... are typed" and "Give types to all parameters, even in closures"
2. The linter enforces omit_obvious_local_variable_types, which requires omitting type annotations when the type is obvious from context

As a contributor, it's unclear which guidance takes precedence — particularly for closure parameters, where the style guide text and the lint rules may overlap.

Existing issue search

I searched existing issues and PRs before filing. Searches included: omit_obvious_local_variable_types, omit_obvious_local_variable_types style guide, closure parameter types, always_specify_types, specify_nonobvious_local_variable_types, type annotation closure, omit_local_variable_types, style guide types closures, and closure types lint. None returned results for this specific discrepancy.

The closest related discussion is in #170435, which covered readability tradeoffs for the new lint rules generally but did not address this style guide section or closure parameters specifically.

Related issues and PRs

• Design doc - Flutter style updates #180607 — Design doc: Flutter style updates (closed)
• Updates to style guide #181985 — Style guide update PR implementing the design doc (merged, did not update this section)
• Modernize framework lints #179089 — "Modernize framework lints" (merged, introduced the lint changes)
• Unify lints in flutter/flutter and flutter/packages #178827 — "Unify lints in flutter/flutter and flutter/packages" (tracking issue)
• [Preview Only] Update type annotation lints for repository #170435 — Preview PR with discussion on type annotation readability tradeoffs

Thanks for your valuable time — I hope this helps!

Proposal

Update the "Avoid using var and dynamic" section of the style guide to reflect the current lint configuration.

Before (current, lines 799-808)

All variables and arguments are typed; avoid `dynamic` or `Object` in
any case where you could figure out the actual type. Always specialize
generic types where possible. Explicitly type all list and map
literals. Give types to all parameters, even in closures and even if you
don't use the parameter.

This achieves two purposes: it verifies that the type that the compiler
would infer matches the type you expect, and it makes the code self-documenting
in the case where the type is not obvious (e.g. when calling anything other
than a constructor).

After (suggested)

Avoid `dynamic` or `Object` in any case where you could figure out the
actual type. Always specialize generic types where possible. Explicitly
type all list and map literals. Give types to all parameters, even in
closures and even if you don't use the parameter.

For local variables, follow the `omit_obvious_local_variable_types` and
`specify_nonobvious_local_variable_types` lints — omit the type annotation
when the type is obvious from context (e.g. constructor calls), and
specify it when it is not.

This makes the code self-documenting in the case where the type is not
obvious (e.g. when calling anything other than a constructor).

Alternatively, if the team prefers different wording, even a one-line note acknowledging the omit_obvious lints would clear up the confusion.