Consider disabling Style/EmptyCaseCondition

[aliismayilov]

I don't find either of following code snippets to be better than the other:

case
when done?       then :done
when exception?  then :exception
else :processing
end

if done?
  :done
elsif exception?
  :exception
else
  :processing
end

in fact, me and colleagues use the first example more often.

original discussion: rubocop/rubocop#3019

[searls]

I appreciate the spirit of this and I'm always open to cases where keywords like case can improve expressiveness, but I think this rule is �a good one and it's going to stay. Reason being: many developers don't know what an empty case statement will do (I didn't until reading this issue, and I've been using Ruby for a while now), and reducing ambiguity in what a program will do ��at� r���untime has some value when we decide which rules are net-beneficial. Closing for now but will gladly welcome others' opinions in the comments

[aliismayilov]

I appreciate the spirit of this and I'm always open to cases where keywords like case can improve expressiveness, but I think this rule is �a good one and it's going to stay. Reason being: many developers don't know what an empty case statement will do (I didn't until reading this issue, and I've been using Ruby for a while now), and reducing ambiguity in what a program will do ��at� r���untime has some value when we decide which rules are net-beneficial. Closing for now but will gladly welcome others' opinions in the comments

Thanks for clarification! I see your point, but I'd like to then ask, wouldn't the same argument (many developers don't know how case statement works) apply in the following example too?

case string
when "foo" then puts "hi!"
when /^foo.*/ then puts "ho!"
end

This might not be the best example, but my point is that it's possible that multiple when conditions can match the variable, but only the first matching one will be executed. This was never confusing [to me], as I've never seen break statements inside case statements in Ruby (and I love this cleanliness). With Ruby's new pattern matching inside case statements might introduce more of these situations, where multiple when conditions might match and developers should know how this works.

I hope, I could explain myself, as with the above example, the standard gem will be happy, but the developers who don't know how case statements work in Ruby will still be confused.

[twe4ked]

I often use empty case statements over if/elsif when there are more than 2-3 options. I find it makes it clearer when the branches aren't different importances.

[nilcolor]

Also, ifs kind of imply hierarchy (imo). While cases is kind of "decision point" with all options to be on the same level of importance... (imo again). Hence

case # rubocop:disable Style/EmptyCaseCondition
when search_term then by_term
...

is kind of common in our code base :) (yeah, this can be disabled but still doesn't)

[ramhoj]

+1 to giving teams the ability to express themselves using if and case as it suits their codebases.

[searls]

FWIW, I don't feel strongly about this one. Think it's worth reopening for discussion.

[ramhoj]

Thank you @searls. I've submitted #787 for your consideration.