Chapter 1 · Practice 4 of 5
Use required named parameters for anything with more than one argument
From Dart and null safety
Why it matters
Named 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.
The Dart docs point out that required-ness and nullability are separate:
| Parameter | Meaning |
|---|---|
required String title | Caller must pass a non-null value |
required String? subtitle | Caller must pass it, but null is allowed |
String label = 'OK' | Optional, non-nullable, has a default |
String? hint | Optional and may be null |
Pick the row that matches the meaning. A required String? is useful when you want the caller to think about the value, even if the answer is "none".
Dart keeps improving constructors too: Dart 3.12 added private named parameters, and Dart 3.13 added primary constructors, a shorter way to declare a constructor and its fields in one header. Check the Dart changelog before adopting new syntax across a shared codebase, so everyone's SDK supports it.
Do
- Use named parameters for widgets and data classes
- Mark parameters
requiredwhen there is no sensible default
Avoid
- Long lists of positional booleans such as
Card(true, false, true)