member_ordering

v1.0.0WarningConfigurableCode Organization

Flags a class member declared before one the configured order puts earlier — a field after a method, a constructor after a getter.

A class read top to bottom should answer the same questions in the same sequence every time: how is it built, what does it hold, what can it do. When the order varies between files, finding a field means scanning the whole class rather than glancing at the top of it.

This rule is in the pedantic preset. It works out of the box with the default order below; enable it in any other preset by name:

rules:
  member_ordering:
    enabled: true

The default order

public_static_fields, private_static_fields,
constructors, named_constructors, factory_constructors,
public_fields, private_fields,
public_getters, private_getters, public_setters, private_setters,
public_methods, private_methods,
build_method

Constructor-first, matching how flutter create, the framework’s own widgets and the Flutter samples are written: the constructor sits directly under the class header with the final fields it initialises below. Fields-first is the older Java-influenced convention — pick it explicitly with order: if that is your house style.

Don’t

class Order {
  void submit() {}

  final int id = 0; // a field, below a method
}

Do

class Order {
  Order(this.id);

  final int id;

  void submit() {}
}

Examples

Choosing fields-first instead

List the categories in the order you want, earliest first:

analysis_options.yaml
many_lints.yaml

many_lints:
  rules:
    member_ordering:
      order:
        - public_fields
        - private_fields
        - constructors
        - public_methods
        - private_methods

rules:
  member_ordering:
    order:
      - public_fields
      - private_fields
      - constructors
      - public_methods
      - private_methods

// Don't — under this order the constructor comes after the fields
class Order {
  Order(this.id);

  final int id;
}

// Do
class Order {
  final int id;

  Order(this.id);
}

A category you leave out is not ordered at all

Only the categories you list are placed. Anything else is skipped rather than pushed somewhere, which is how you order part of a class and leave the rest to taste:

rules:
  member_ordering:
    order:
      - constructors
      - public_methods

// Accepted — getters and static fields are unlisted, so their position is
// not this rule's business; only `constructors` before `public_methods` is.
class Session {
  Session(this.token);

  static const timeout = Duration(minutes: 30);

  void refresh() {}

  String get isValid => token;

  final String token;
}

A widget’s `build` goes last

build_method only applies to a Widget subclass — that is the one whose build renders. Put it last in your order and it stays at the bottom:

rules:
  member_ordering:
    order:
      - constructors
      - public_fields
      - public_methods
      - build_method

Ordering by override rather than by visibility

overridden_methods and static_methods are more specific than the plain method categories, so listing one pulls those members out into their own block:

rules:
  member_ordering:
    order:
      - constructors
      - public_fields
      - overridden_methods
      - public_methods
      - private_methods

// Don't — `dispose` is annotated @override, so it belongs before `refresh`
class Controller {
  Controller();

  void refresh() {}

  @override
  void dispose() {}
}

// Do
class Controller {
  Controller();

  @override
  void dispose() {}

  void refresh() {}
}

Options

Option	Type	Default	Description
`order`	list of strings	the constructor-first order above	The member categories, earliest first. A category left out is not ordered at all, and an unrecognised name is ignored

Recognised categories: public_static_fields, private_static_fields, public_fields, private_fields, constructors, named_constructors, factory_constructors, public_getters, private_getters, public_setters, private_setters, public_methods, private_methods, static_methods, overridden_methods, build_method.

Known limitations

==, hashCode and toString are never reported. They are a conventional trio written as one block, and Dart forces hashCode to be a getter while == is an operator — so any getters-before-methods order would split them.

Operators are never reported, for the same reason.

A Riverpod Notifier.build is never treated as build_method. That is the state initialiser and idiomatically comes first. Only a Widget subclass has its build ordered last.

A field declaring several variables is private if any of them is. int a, _b; counts as a private field.

A member matches its most specific listed category. A static private method is static_methods if you listed that, otherwise private_methods — so listing both puts every static method in the static block, private ones included.

A primary constructor’s body has no category. It is part of the class header, not a member that can be moved.

No quick fix. Moving members is a large mechanical edit that frequently drags doc comments and // region markers out of place.

Turning this rule off

To disable this rule:

rules:
  member_ordering: false

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

arguments_ordering — Keep named arguments in a configured order.
initializers_ordering — Keep constructor initializers in field order.
map_keys_ordering — Keep map literal keys in a configured order.
parameters_ordering — Keep named parameters in a configured order.