initializers_ordering

v1.0.0WarningConfigurableCode Organization

This rule flags a constructor whose field initializers are not in the same order as the fields they assign.

Unlike its ordering siblings this rule has a useful default: it matches the initializer list against the class’s own field declaration order rather than against an alphabet. That order is already a decision the class made, so following it costs nothing and makes a missing initializer visible as a gap rather than as a name buried in a differently-ordered list.

Initializers that are not plain field assignments — super(), assert(), a redirect — are skipped, since their position is fixed by the language or by intent.

This rule is in the pedantic preset.

Don’t

class Point {
  final int x;
  final int y;

  Point(int a, int b) : y = b, x = a;
}

Do

class Point {
  final int x;
  final int y;

  Point(int a, int b) : x = a, y = b;
}

Enabling this rule

This rule is in the pedantic preset, so it is enabled by preset: pedantic or by name:

many_lints.yaml

rules:
  initializers_ordering:
    enabled: true

Options

analysis_options.yaml

analysis_options.yaml

many_lints:
  rules:
    initializers_ordering:
      order: alphabetical

many_lints.yaml

many_lints.yaml

rules:
  initializers_ordering:
    order: alphabetical

Option	Type	Default	Description
order	string	—	Sort by name instead of by field order: alphabetical, alphabetical_case_sensitive or by_length

Turning this rule off

To disable this rule:

many_lints.yaml

rules:
  initializers_ordering: false

To keep the rule on but skip certain paths, use per-rule exclude.

Related rules

• arguments_ordering — Keep named arguments in a configured order.
• map_keys_ordering — Keep map literal keys in a configured order.
• member_ordering — Keep class members in a configured order.
• parameters_ordering — Keep named parameters in a configured order.