proposal: unneccessary_ternary_operator

[jacob314]

unneccessary_ternary_operator

Description

Unnecessary ternary operator. Same result can be achieved with less code.

Details

A search of Dart code in g3 shows 150 cases where people have written the pointless ternary operator code in Dart:
foo ? true : false instead foo
and 70+ cases of
foo ? false : true instead !foo

Likely code reviewers caught even more cases before the code was committed.
Quick assists to refactor if / else to use ternary operators can accentuate the number of uncaught versions of this unnecessarily verbose code as see in For example, flutter/devtools#4890 caught one such case.

Give a detailed description that should provide context and motivation. Ideally this could be used directly in the rule's documentation.

Kind

This enforces

Bad Examples

bool baz() => foo ? true : false;
bool bar() => foo ? false : true;

Good Examples

bool baz() => foo;
bool bar() => !foo;

Discussion

I wouldn't have thought this lint would be needed but I missed catching an example like this after applying automated fixes to a code base and the g3 codebase has 158 examples of ? true : false and 75 examples of ? false : true so users do make this mistake in practice likely when refactoring code and forgetting to fully simplify the code.

Discussion checklist

[incendial]

Added this rule to Dart Code Metrics https://dartcodemetrics.dev/docs/rules/common/avoid-unnecessary-conditionals 🙂

https://dartcodemetrics.dev/docs/rules/common/prefer-conditional-expressions auto-fix now also removes boolean literals

[a14n]

https://dart.dev/tools/linter-rules#avoid_bool_literals_in_conditional_expressions ?

[ALuferau]

Hello. Maybe good to also handle such cases on the if expression - to warning about comparison between Boolean variables and Boolean literals. Like in next code:

    const bool value = true;
    if (value == true) { // <-- should be if (value) {
      //
    } else {
      //
    }

[srawlins]

@FMorschel was any of your work in the last release related to this? I don't think it's a big impact; but I'd love to close this if it is covered by an existing rule.