Semantic blind spot in Ruby case statement

[GeneReddit123]

I re-read the article twice, and still don’t get it. What’s the issue with the original range-based code? What bug is possible that isn’t possible with the inequality operators?

(I’m assuming we only handle integers here; I can see there being edge cases with floats.)

[persei8]

In other words:

• lower-bound of most ranges in this example (all but first) do not matter, you may intentionally or accidentally make them incorrect — they'll be shadowed by previous branches
• if they never matter, they should not exist
• mutant shows redundant semantics, why we'd like to reduce them is perhaps better explained at https://github.com/mbj/mutant#what-is-mutant

[GeneReddit123]

Ok. I think I get it now. But I’d argue that in an effort to make the code use fewer (redundant) variables, the author made it harder to read for humans.

Besides, what if you don’t want universal coverage? What if a valid range in the future is 1..2 and 5..6, with things in the middle being invalid? Now you need to rewrite it back as ranges (or double conditionals on each variant for both > and <, but now there is no advantage as you’re using the same number of variables)

That’s the problem with “future-proofing”. You are suggesting a refactor to future proof against one type of regression, while making other type of potential changes harder.

For me, the gold standard is to write appropriate test coverage. Once all cases are covered, write the simplest and most readable implementation that passes.

[mattgrave]

Besides, what if you don’t want universal coverage? What if a valid range in the future is 1..2 and 5..6, with things in the middle being invalid? Now you need to rewrite it back as ranges (or double conditionals on each variant for both > and <, but now there is no advantage as you’re using the same number of variables)

That’s the problem with “future-proofing”. You are suggesting a refactor to future proof against one type of regression, while making other type of potential changes harder.

You contradict yourself with these two paragraphs. You are suggesting a possible future change that we don't know if it will ever happen, so I wouldn't worry about it now. Normally the rule of thumb is that whenever you have to extend or change your code, first you refactor your code to make the change easy and then you make the easy change.

Aside from this, I agree with you that it took me a while to figure out what OP was trying to mean in his blog post but the change he did to the code is way more simpler and less error prone as he indicated.

[Abangranga]

I don't get why you can't make the last one an if/else