Hacker News new | ask | show | jobs
by CGamesPlay 2267 days ago
What did you do in cases where the fall through was desired behavior? Did the resulting code (replacing a fall through with a nested if or something?) look better or worse as a result?

The typical way to handle this at companies that don't have a static-type-checker department is to require a comment that says /* falls through */ at the end of the switch. Why was such a simple solution inappropriate here?

2 comments

Because code reviews are more fallible than automatic linters, and OP had the luxury of working somewhere that the noisy people didn't fight for an anti-feature.
I wasn't talking about requiring it in code review though. The OP didn't make an automatic linter that issued a warning when you did this implicitly, he removed the ability to do it entirely. With a linter, you can add a comment, like /* falls through */ to disable the lint warning. With the OP's change you can... use a series of if-else blocks? The alternative isn't listed, which is why I asked.

Sorry about your last company, though. Sounds like it was annoying to work there!

OP here.

Explicitly-annotated fallthrough was still allowed; I codified a particular annotation that the analysis tool understood and allowed. I removed implicit fallthrough, but explicit fallthrough can be quite useful sometimes.

Sounds like that's what they did:

The cleanup diffs I’d written that afternoon mostly just annotated clearly-intentional fallthroughs