proposal: prefer_merging_statement

[FMorschel]

prefer_merging_statements

Description

Prefer merging switch statements with identical bodies to improve code readability and reduce redundancy.

Details

Merging switch statements with identical bodies improves code readability and reduces redundancy.

Kind

This lint enforces style advice by promoting code readability and reducing redundancy through the merging of identical switch statement bodies.

Bad Examples

switch (value) {
  case value1:
    return 1;   // Lint here
  case value2:
    return 3;
  case value3:
    return 1;   // Lint here
  default:
    return 2;
}

switch (value) {
  value1 => 1;   // Lint here
  value2 => 3;
  value3 => 1;   // Lint here
  _ => 2;
}

Good Examples

switch (value) {
  case value1:
  case value3:
    return 1;
  case value2:
    return 3;
  default:
    return 2;
}

switch (value) {
  case value1 || value3:
    return 1;
  case value2:
    return 3;
  default:
    return 2;
}

switch (value) {
  value1 || value3 => 1;
  value2 => 3;
  _ => 2;
}

Discussion

---

Edit

This would complement unreachable_switch_case:

This case is covered by the previous cases.
Try removing the case clause, or restructuring the preceding patterns.

---

The future quick-fixes could be the two above examples where the case value3 is moved up removing the current duplicated code or for it to merge with the other statement using the || operator.

I believe if this is implemented it should be added to Effective Dart.

Discussion checklist

• List any existing rules this proposal modifies, complements, overlaps or conflicts with.
• List any relevant issues (reported here, the [SDK Tracker], or elsewhere).
• If there's any prior art (e.g., in other linters), please add references here.
• If this proposal corresponds to [Effective Dart] or [Flutter Style Guide] advice, please call it out. (If there isn't any corresponding advice, should there be?)
• If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.

[FMorschel]

Inspired by #56597

[FMorschel]

This would be pretty useful in contexts where there is a big switch statement and some refactoring was done. So that the user can see the identical body.

I know this could lead to false negatives but I think in this case it is better to have some form or warning than to not have any.

[FMorschel]

This would be great with #56180 and would probably relate to #59530

[FMorschel]

Somewhat related to #60008.