enum_constants_ordering

v1.0.0WarningConfigurableCode Organization

Flags an enum whose constants are not in the order you configure.

An enum is a list a reader scans rather than reads, and finding a constant in an unordered list of twenty means checking all twenty. Ordering also makes an addition show up in a diff as one line in the middle rather than one appended at the end, which is where duplicates hide.

This rule is in the pedantic preset, which sets order: alphabetical. Under any other preset it reports nothing until you set order: — the useful order for an enum is often semantic, and small, medium, large is correctly ordered exactly as it stands.

many_lints:
  rules:
    enum_constants_ordering:
      order: alphabetical

rules:
  enum_constants_ordering:
    order: alphabetical

Don’t

With order: alphabetical:

enum Fruit { banana, apple, cherry }

Do

enum Fruit { apple, banana, cherry }

Examples

`alphabetical` — case-insensitive

The default, and what a reader scanning for a name expects. Case-sensitive sorting puts every capitalised name in a block before the lowercase ones, which reads as two lists rather than one.

rules:
  enum_constants_ordering:
    order: alphabetical

// Don't
enum LogLevel { warn, Debug, error }   // LINT on `Debug`

// Do
enum LogLevel { Debug, error, warn }

`alphabetical_case_sensitive`

Compares the raw strings, so every uppercase name sorts before every lowercase one:

rules:
  enum_constants_ordering:
    order: alphabetical_case_sensitive

// Don't
enum LogLevel { Debug, error, Warn }   // LINT on `Warn`

// Do
enum LogLevel { Debug, Warn, error }

`by_length`

Longest name last. Purely visual, but it is a real house style for enum bodies. Names of equal length fall back to alphabetical, so the order is total:

rules:
  enum_constants_ordering:
    order: by_length

// Don't
enum Size { extraLarge, small, medium }   // LINT on `small`

// Do
enum Size { small, medium, extraLarge }

Scope it where a semantic order is the point

Some enums are ordered by meaning and alphabetising them is a regression. Scope the rule rather than annotating each one:

rules:
  enum_constants_ordering:
    order: alphabetical
    exclude: ['lib/**/domain/**']

// lib/checkout/domain/order_stage.dart — not reported
enum OrderStage { created, paid, shipped, delivered }

Options

Option	Type	Default	Description
`order`	string	`—`	`alphabetical`, `alphabetical_case_sensitive` or `by_length`. Unset means the rule is silent

Known limitations

Only the first out-of-order constant is reported. One misplaced name makes every later name look wrong too, and reporting them all would turn one edit into a wall of diagnostics. Fix the reported one and re-run to see the next.

No quick fix. Reordering enum constants changes their index, which is not always inert — a persisted or serialised index would shift under the rewrite. The move is left to you.

An unrecognised order: falls back to alphabetical rather than throwing, because a plugin cannot report a diagnostic against a YAML file. Check the spelling if the order you get is not the one you asked for.

Turning this rule off

To disable this rule:

rules:
  enum_constants_ordering: false

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

pattern_fields_ordering — Keep pattern fields in a configured order.
record_fields_ordering — Keep record named fields in a configured order.
avoid_missing_enum_constant_in_map — Cover every enum constant in a map keyed by that enum.
prefer_enums_by_name — Use .byName() instead of .firstWhere() to look up enum values by name.