8.5.a. The use of goto statements shall be restricted as per Rule 1.7.c.

8.5.b. C Standard Library functions abort(), exit(), setjmp(), and longjmp() shall not be used.

Reasoning: Algorithms that utilize jumps to move the instruction pointer can and should be rewritten in a manner that is more readable and thus easier to maintain.

Enforcement: These rules shall be enforced by an automated scan of all modified or new modules for inappropriate use of forbidden tokens. To the extent that the use of goto is permitted, code reviewers should investigate alternative code structures to improve code maintainability and readability.


Across my decades of programming, I've found that outright bans of the break keyword (and, to a lesser extent, bans multiple return statements in a function) is more harmful than helpful. In particular, I have seen cases where programmers wind up writing much more complicated code when they try to omit break. This happens when they introduce an otherwise unnecessary flag-variable and conditional expression.

Rather than banning all use of certain keywords that can be misused, a more nuanced coding rule might be better. For example, it is hard for me to see how a function with a single loop containing a a handful of lines of code with one use of break to exit the loop under exceptional circumstances would make the code less readable or maintainable than alternative structures.

Of relevance, I see that the MISRA-C++:2008 guidelines promote a more nuanced rule:

    For any iteration statement there shall be no more than one break or goto statement used for loop termination.

In short, I believe that the goal of making code as readable and easy to maintain as possible is not always achieved by banning break altogether. That's not to say that anyone should be writing functions with cyclomatic complexity greater than 10, with or without breaks.