Skip to content

prefer_returning_condition

v1.0.0 Warning Control Flow

This rule flags an if that returns true with a following return false (or the reverse).

if (x > 0) return true; return false; is the condition itself, spelled out in three lines. return x > 0; says it once, and the reader does not have to check that the two branches really are opposites — which is exactly the check that gets skipped when one of them is later edited.

An if with the opposite literal on the next statement:

class Player {
int get rating => 0;
}
bool isEligible(Player player) {
if (player.rating > 1200) {
return true;
}
return false;
}

The explicit else is the same mistake:

class Player {
int get rating => 0;
}
bool isEligible(Player player) {
if (player.rating > 1200) {
return true;
} else {
return false;
}
}

An inverted pair works out to the negated condition:

class Player {
bool get isBanned => false;
}
bool canPlay(Player player) {
if (player.isBanned) {
return false;
}
return true;
}
class Player {
int get rating => 0;
bool get isBanned => false;
}
bool isEligible(Player player) => player.rating > 1200;
bool canPlay(Player player) => !player.isBanned;

Both branches returning the same literal is a different mistake, reported by function_always_returns_same_value instead.

A pattern case (if (x case final int n)) is skipped, since it binds variables the returned expression may use.

Only a bare true/false literal counts. return isEligible; after an if is a value, not a spelled-out condition, and is not reported.

This rule is in the opinionated preset.

To disable this rule:

many_lints.yaml
rules:
prefer_returning_condition: false

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