Update style guide (#184478)

Piinks · loic-sharma · web-flow · commit 0201778810c3 · 2026-04-01T20:59:33.000Z
Fixes #184441 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.  [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md --------- Co-authored-by: Loïc Sharma <737941+loic-sharma@users.noreply.github.com>
diff --git a/docs/contributing/Style-guide-for-Flutter-repo.md b/docs/contributing/Style-guide-for-Flutter-repo.md
@@ -794,22 +794,23 @@ Use `switch` with no `default` case if you are examining an enum, since the anal
 Avoid using `if` chains, `? ... : ...`, or, in general, any expressions involving enums.
 
 
-### Avoid using `var` and `dynamic`
-
-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).
-
-Always avoid `var` and `dynamic`. If the type is unknown, prefer using
-`Object` (or `Object?`) and casting, as using `dynamic` disables all
-static checking.
+### Prefer explicit types and avoid `dynamic`
+
+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).
+
+Avoid `dynamic`. If the type is unknown, prefer using `Object` (or
+`Object?`) and casting, as using `dynamic` disables all static checking.
 
 
 ### Avoid using `library` and `part of`.
