Fall-through in switch statements is common feature of C-family languages. I'm not sure you'll get a general consensus on whether it's a good feature. The problem I find with it is that it tends to be easy to forget a break
statement when coding and not notice it is missing when reading code. I think it can be a little hard to follow code like this:
switch (cond)
{
case a:
stepX();
case b:
stepY();
stepZ();
break;
case c:
stepP();
default:
stepR();
}
It's easy to miss the break and then you might wonder if the fall-through was intentional or the break
was omitted inadvertently. I think it's valid to forbid all fall-through logic in switch statements as part of coding standard for this reason.
On the other hand, the particular case you show, IMO, is probably the least egregious way to use this feature. There's no real confusion and if someone doesn't understand it, they'll have learned something once they do the research and/or ask about it. But I think it's totally reasonable to avoid subjectivity in your standards and say no.
I think it comes down to how your team dynamic works. If you have people who want clear-cur rules, you might want to just say fall-through is either fine to use or not. If there's tolerance for more nuance in code reviews, maybe you judge each usage independently. If everyone else on the team is comfortable with fall-through and like it, maybe you bless any use of it. The worst situation will be if fall-through is only used occasionally and you have team members who don't grok it.
On a side note, there's another way to accomplish this logic that might be worth considering. Something along these lines:
Set<ItemStatus> notReadyStatuses = EnumSet.of(
ItemStatus.Preparing,
ItemStatus.Ordered,
ItemStatus.Voiding,
ItemStatus.Delayed,
ItemStatus.OutOfStock);
Then the condition becomes:
if (notReadyStatuses.contains(itemStatus)) {
orderStatus = OrderStatus.NotReady;
}
Thanks to Vincent Savard for the recommendation on using EnumSet.