Barr Group TwitterBarr Group Vimeo


The following C coding rules relate to unconditional jumps in embedded software:

Rule 8.5.a.) As stated in an another rule, the keywords goto, continue, and break are never to be used. This is so they cannot be used to create unconditional jumps.


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




These rules shall be enforced by an automated scan of all modified or new modules for inappropriate use of these tokens.


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.

What’s happening and how it’s done. Get in the know.

Sign Up for Our Newsletter

Receive free how-to articles, industry news, and the latest info on Barr Group webinars and training courses via email. 

To prevent automated spam submissions leave this field empty.