flutter-dart-code-review

Flutter/Dart Code Review Best Practices

Comprehensive, library-agnostic checklist for reviewing Flutter/Dart applications. These principles apply regardless of which state management solution, routing library, or DI framework is used.

1. General Project Health

• Project follows consistent folder structure (feature-first or layer-first)
• Proper separation of concerns: UI, business logic, data layers
• No business logic in widgets; widgets are purely presentational
• pubspec.yaml is clean — no unused dependencies, versions pinned appropriately
• analysis_options.yaml includes a strict lint set with strict analyzer settings enabled
• No print() statements in production code — use dart:developer log() or a logging package
• Generated files (.g.dart, .freezed.dart, .gr.dart) are up-to-date or in .gitignore
• Platform-specific code isolated behind abstractions

2. Dart Language Pitfalls

• Implicit dynamic: Missing type annotations leading to dynamic — enable strict-casts, strict-inference, strict-raw-types
• Null safety misuse: Excessive ! (bang operator) instead of proper null checks or Dart 3 pattern matching (if (value case var v?))
• Type promotion failures: Using this.field where local variable promotion would work
• Catching too broadly: catch (e) without on clause; always specify exception types
• Catching Error: Error subtypes indicate bugs and should not be caught
• Unused async: Functions marked async that never await — unnecessary overhead
• late overuse: late used where nullable or constructor initialization would be safer; defers errors to runtime
• String concatenation in loops: Use StringBuffer instead of + for iterative string building
• Mutable state in const contexts: Fields in const constructor classes should not be mutable
• Ignoring Future return values: Use await or explicitly call unawaited() to signal intent
• var where final works: Prefer final for locals and const for compile-time constants
• Relative imports: Use package: imports for consistency
• Mutable collections exposed: Public APIs should return unmodifiable views, not raw List/Map
• Missing Dart 3 pattern matching: Prefer switch expressions and if-case over verbose is checks and manual casting
• Throwaway classes for multiple returns: Use Dart 3 records (String, int) instead of single-use DTOs
• print() in production code: Use dart:developer log() or the project's logging package; print() has no log levels and cannot be filtered