Flutter Best Practices

Chapter 1 of 8 · 5 practices · 4 min · 4-question quiz

Dart and null safety

How to use Dart's sound null safety and modern language features so the analyzer catches bugs before your users do.

Start: Model "might be missing" in the type, not in comments

5 practices in this chapter

  1. 1Model "might be missing" in the type, not in commentsDart has sound null safety. The Dart docs define it this way: if an expression has a static type that does not permit null, then no possible execution of that expression can ever evaluate to…
  2. 2Prefer flow analysis over the ! operatorThe ! operator casts a nullable value to its non-nullable type. The Dart docs are blunt about it: the ! operator always throws if the value is null. Each ! is a runtime crash you have chosen…
  3. 3Use late only when initialization order is truly under your controlThe late modifier tells Dart to enforce a variable's constraints at runtime instead of at compile time. The Dart docs warn that any use of a late field could fail, and there is nothing visible at…
  4. 4Use required named parameters for anything with more than one argumentNamed parameters make call sites readable: Button(label: 'Save', onPressed: save) says more than Button('Save', save). Mark the ones the caller must provide with required.
  5. 5Turn on the recommended lints and treat analyzer warnings as workThe analyzer is your cheapest reviewer. New Flutter projects include the flutter_lints package, and the Flutter performance docs specifically recommend it so you are reminded to use const where…

Check yourself on this chapter

4 questions, right here once you are signed in. Your progress is saved as you read.

Sign up for the quiz