D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks

René J.V. Bertin noreply at phabricator.kde.org
Sun Sep 23 20:33:51 BST 2018


rjvbb added a comment.


  >   Can you explain in more detail how an unreachable `break` after a `return` statement makes the code more readable?
  
  It's a shortist word that's easily recognisable that serves as a closing tag. Remove it, and my first impression will be that there's a fallthrough (because I'm not that used to returns in a switch). And a default: without break feels ... incomplete, makes me wonder if I missed a brace.
  
  >   until then we have to live with the all-caps.
  
  I'll point out that we're no longer living with Q_FOREACH and that nothing forbids anyone to provide a less conspicuous pattern than Q_FALLTHROUGH.
  
  >   Apart from that, fallthroughs are not very common, and one could argue that they should be drawing a reader's attention.
  
  Maybe, but there's also a reason why we avoid all-caps in things that have to be easily readable.
  
  >   When case labels follow directly after others, no annotation is necessary.
  
  I don't disagree, but it *is* an exception that you can easily extend to other cases where it's evident that a fallthrough is intended:
  
    switch (type) {
        case TYPE_A_OR_B:
           do_something_for_a_or_b();
           // it should be obvious that we're continuing straight to B
        case TYPE_B:
           do_something_for_b();
           break;
  
  After all that mumbling in my beard (because that's what it is really) I wouldn't be doing that so much if we were encouraged (or obliged) to use braces systematically:
  
    switch (type) {
        case A: {
            return theFavour;
        }
        case B: {
            catchB();
            Q_FALLTHROUGH;
        }
        default: {
            catchAll();
        }
    }

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D15694

To: aaronpuchert, #kdevelop
Cc: rjvbb, brauch, mssola, kossebau, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180923/23f8f58d/attachment.html>


More information about the KDevelop-devel mailing list