<table><tr><td style="">aaronpuchert added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D15694">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D15694#330687" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">D15694#330687</a>, <a href="https://phabricator.kde.org/p/rjvbb/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@rjvbb</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><p>As mentioned on another ticket, I don't like the idea of not putting <tt style="background: #ebebeb; font-size: 13px;">break</tt>s, no matter how clever the compiler and hard-coded choice of compiler options.</p></div>
</blockquote>
<p>The compiler doesn't need to be clever, it has to understand control flow anyway to compile the program. With Clang, you can actually see the generated control flow graph of your source file with the options <tt style="background: #ebebeb; font-size: 13px;">--analyze -Xanalyzer -analyzer-checker=debug.DumpCFG</tt>.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>I don't think you gain anything from it, and it doesn't improve code readability either for me</p></blockquote>
<p>Can you explain in more detail how an unreachable <tt style="background: #ebebeb; font-size: 13px;">break</tt> after a <tt style="background: #ebebeb; font-size: 13px;">return</tt> statement makes the code more readable? Actually <a href="https://phabricator.kde.org/tag/framework_syntax_highlighting/" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">#framework_syntax_highlighting</a> distinguishes between control flow keywords and other keywords. Depending on your color scheme, you'll see if there is a terminator or not.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Making it obligatory to add a token confirming that fallthrough is intended is a good idea, though using a largish term in all-caps like <tt style="background: #ebebeb; font-size: 13px;">Q_FALLTHROUGH</tt> also doesn't improve readibilty.</p></blockquote>
<p>With C++17 you can use <tt style="background: #ebebeb; font-size: 13px;">[[fallthrough]];</tt> — until then we have to live with the all-caps. Apart from that, fallthroughs are not very common, and one could argue that they should be drawing a reader's attention.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>And what about the most common type of fallthrough, are we really going to have to write something like the following?</p></blockquote>
<p>When case labels follow directly after others, no annotation is necessary. Only when there is another statement in between. That doesn't happen very often, and if it does, the annotation certainly doesn't hurt.</p>
<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">switch (type) {
case TYPE_A: // no fallthrough annotation needed
case TYPE_B: // no fallthrough annotation needed
case TYPE_C: // no fallthrough annotation needed
case TYPE_D:
whatever();
break; // annotation would be necessary if we didn't break
default:
anyway();
// break optional
}</pre></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D15694">https://phabricator.kde.org/D15694</a></div></div><br /><div><strong>To: </strong>aaronpuchert, KDevelop<br /><strong>Cc: </strong>rjvbb, brauch, mssola, kossebau, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd<br /></div>