prefer_initializing_formals

Use initializing formals when possible.

DO use initializing formals when possible.

Using initializing formals when possible makes your code more terse.

BAD:

class Point {  num? x, y;  Point(num x, num y) {  this.x = x;  this.y = y;  } } 

GOOD:

class Point {  num? x, y;  Point(num this.x, num this.y); } 

BAD:

class Point {  num? x, y;  Point({num? x, num? y}) {  this.x = x;  this.y = y;  } } 

GOOD:

class Point {  num? x, y;  Point({required num this.x, required num this.y}); } 

NOTE: This rule will not generate a lint for named parameters unless the parameter name and the field name are the same. The reason for this is that resolving such a lint would require either renaming the field or renaming the parameter, and both of those actions would potentially be a breaking change. For example, the following will not generate a lint:

class Point {  bool? isEnabled;  Point({bool? enabled}) {  this.isEnabled = enabled; // OK  } } 

NOTE: Also note that it is possible to enforce a type that is stricter than the initialized field with an initializing formal parameter. In the following example the unnamed Bid constructor requires a non-null int despite amount being declared nullable (int?).

class Bid {  final int? amount;  Bid(int this.amount);  Bid.pass() : amount = null; } 

To enable the prefer_initializing_formals rule, add prefer_initializing_formals under linter > rules in your analysis_options.yaml file:

linter:  rules:  - prefer_initializing_formals 

If you're instead using the YAML map syntax to configure linter rules, add prefer_initializing_formals: true under linter > rules:

linter:  rules:  prefer_initializing_formals: true