My Favourite Diff

Recent GCC can diagnose the situation where a switch case falls through without a &#x2F;* fallthrough *&#x2F; comment.[1]<p>C++17 has a comment-like language feature for demarcating desired fallthrough.<p>Fallthrough in case processing is often useful; it&#x27;s just not such a great default.<p>In the TXR Lisp tree-case[2] construct, any case which returns the : object falls through to the next case.<p>This is used all over the place in the library.<p>--<p>[2] <a href="https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gcc-9.3.0&#x2F;gcc&#x2F;Warning-Options.html#index-Wimplicit-fallthrough" rel="nofollow">https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gcc-9.3.0&#x2F;gcc&#x2F;Warning-Options...</a><p>[1] <a href="https:&#x2F;&#x2F;www.nongnu.org&#x2F;txr&#x2F;txr-manpage.html#N-03D834A5" rel="nofollow">https:&#x2F;&#x2F;www.nongnu.org&#x2F;txr&#x2F;txr-manpage.html#N-03D834A5</a>

_Often my biggest contribution isn’t being the only one who is able to fix something, but being the only one who realises something is fixable._<p>I feel relatable. At all the placed I&#x27;ve worked, people realize the problem, sometime find the solution, but most of the time, they won&#x27;t fix it, unless it directly affect their code&#x2F;project&#x2F;product. As a result, technical debt keeps bubble up and we have more and more issues.<p>Right now, the only thing I can do is just to keep fixing issues as I encounter them. But that&#x27;s for the code, I don&#x27;t have any solution for the &quot;people&quot; problem.

This reminded me of Raymond Chen&#x27;s blurb article on his blog, The Old New Thing:<p><a href="https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20110118-00&#x2F;?p=11733" rel="nofollow">https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20110118-00&#x2F;?p=11...</a><p>For whatever reason that heavily influenced me, and now I almost always submit patches together with my bug reports. Sometimes its a whole lot more work, but I feel like this practice pays dividends in the amount you learn as well as the comraderie it fosters with the upstream devs.

One annoying thing about the war on case fallthrough at the language level is the lack of imagination.<p>`continue` is a thing, compliments switch&#x27;s existing `break` statement usage and is overall a much better solution for explicitly specifying fallthrough then returning special objects or c#&#x27;s abuse of goto.

Since there&#x27;s not much context here: the article, which I enjoyed, ends with &quot;Be the change you want to see in the world&quot;, and shows how the author exemplified this by coding a fix to a persistent source of PHP bugs at $WORK.

As a technical aside (I know it&#x27;s not the main point, but still): with the ubiquity of Git workflows employing pre-merge checking on the platform of choice (e.g. Github or a CI tool), this is rather easily done via a rule in an off-the-shelf linter. No `break` in a `case`? Can&#x27;t merge it.<p>As a language-design aside, `switch` in general is stinky stuff. Not just with the fall-through: it also violates the regular C-style syntax for no particular reason, having a mini-syntax of its own instead.<p>But the most perverse thing I&#x27;ve seen done with `switch` is using it as `if`:<p><pre><code> switch (true) { case ($a == $b): ... case ($c == $d): ... case (itsFullMoonToday()): ... default: ... }</code></pre>

On the contrary, I&#x27;ve heard of a story where a team decided to apply some new tool to their codebase which warned about a missing break, inserted the break so the warning disappeared, <i>&quot;fixed&quot; the failing tests that now resulted</i>, and then upon the next release was subsequently screamed at by numerous customers for the unwanted behaviour change.<p><i>but in a very high-level language like PHP, there’s really no reason for switch to fall through at all</i><p>I disagree. Switch fallthrough is very useful because it can reduce code duplication, especially when the logic has a ladder-like structure. Trying to impose increasingly draconian and such arbitrary rules is only going to lead to a self-fulfilling-prophecy where all the intelligent developers will get fed up and leave, and what&#x27;s left are those which will continue to create tons of bugs some other way instead.

I did a similar thing for Chrome back in the day, to have the compiler check an `override` annotation:<p><a href="http:&#x2F;&#x2F;neugierig.org&#x2F;software&#x2F;chromium&#x2F;notes&#x2F;2011&#x2F;01&#x2F;clang.html" rel="nofollow">http:&#x2F;&#x2F;neugierig.org&#x2F;software&#x2F;chromium&#x2F;notes&#x2F;2011&#x2F;01&#x2F;clang.h...</a>

Just a reminder that in most compiled and JIT optimized languages with switches, this<p><pre><code> switch (c) { case 4: return 30; case 5: return 70; default: return 0; } </code></pre> compiles to the same instructions and therefore same performance as<p><pre><code> if (c == 4) { return 30; } else if (c == 5) { return 70; } else { return 0; } </code></pre> As a side note, it&#x27;s easier to see accidental fallthroughs if you write switch statements like this.<p><pre><code> switch (c) { case 4: { return 30; } break; case 5: { return 70; } break; default: { return 0; } break; </code></pre> But in my opinion, the `if` statement is more clear in both cases, and only one level of indentation instead of 2.

Google applies ErrorProne in the default javac toolchain to mitigate this for Java builds: <a href="https:&#x2F;&#x2F;errorprone.info&#x2F;bugpattern&#x2F;FallThrough" rel="nofollow">https:&#x2F;&#x2F;errorprone.info&#x2F;bugpattern&#x2F;FallThrough</a>

Recently, my coworker basically asked if he should set a TTL on a password for a job we were running. We said yeah, but our code would need changes to accommodate it before it expired and we didn&#x27;t have time to make them.<p>I joked that we&#x27;d make a JIRA ticket that we&#x27;d repeatedly deprioritize until our code mysteriously broke in 6 months, but then my coworker actually made an Outlook reminder for when we had a month left!<p>I thought that was really smart, so I guess I learned a lesson about actually solving problems instead of just pointing them out like a smart ass.

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?<p>The typical way to handle this at companies that don&#x27;t have a static-type-checker department is to require a comment that says &#x2F;* falls through *&#x2F; at the end of the switch. Why was such a simple solution inappropriate here?

Some of my favourite diffs were related to linters:<p>- Linting files different from origin&#x2F;master in a pre-commit hook.<p>- Linting everything in CI.<p>- Making the linter rules stricter (mypy does a great job of having several orthogonal strictness flags, so you can pick the set appropriate for your familiarity with the tool).<p>- Implementing project-specific lint checks.

Cool story.<p>I use Swift. It does not have default switch fallthrough. After a couple of versions, I learned about the fallthrough statement.<p>I remember being frustrated by it, at first, but, like so many Swift oddities, it rapidly became second nature; thus, proving out that one of the goals of Swift is to train developers to write code properly.

If the author discovered tslint&#x2F;eslint he&#x27;d be surprised that this problem was long solved in the JS world :)

So many cases about this and that, pro and cons of switch fall-through, while Pascal was King from beginning.