Skip to content

prefer_getter_over_method

v1.0.0 Warning Code Quality

This rule flags a no-argument method whose body only reads a value, where a getter reads as the property it is.

order.getTotal() and order.total return the same thing, but only the second reads as a property of the order. Effective Dart’s rule is that a member doing no real work and taking no arguments should be a getter; the empty parentheses otherwise suggest something happens when you call it.

This rule is in the pedantic preset, because where the line falls between “a property” and “a call” is a genuine API-design judgement.

See also: Effective Dart: prefer a getter

The empirical run against a production codebase turned up three classes of member that must keep their parentheses, and all three are excluded:

  • A body that calls anything. Clock.now() and sixDigitCode() answer differently on each call, and a getter promises a stable property. Only a body built from field reads and operators qualifies.
  • A conventional name. toJson is what every serialiser looks for, call is the invocation operator in all but name, and copyWith/toList are established shapes a reader expects invoked.
  • A Stream or Future return. A stream is something you subscribe to, not a property you read, so watchUser() keeps its parentheses.

Also skipped: a void method (called for an effect), an @override (which must keep the supertype’s shape), a generic method (a getter cannot take type arguments), and a block body, which may be doing the work the parentheses promise.

class Order {
final int amount;
int total() => amount * 2;
}
class Order {
final int amount;
int get total => amount * 2;
}

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

many_lints.yaml
rules:
prefer_getter_over_method:
enabled: true

To disable this rule:

many_lints.yaml
rules:
prefer_getter_over_method: false

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