Barr Group TwitterBarr Group Vimeo


The following C coding rules relate to certain keywords of the language that should be disfavored to reduce bugs:

Rule 1.7.a.) The auto keyword shall not be used.

Rule 1.7.b.) The register keyword shall not be used.

Rule 1.7.c.) The goto keyword shall not be used.

Rule 1.7.d.) The continue keyword shall not be used.

Rule 1.7.e.) The break keyword shall not be used outside of a switch statement.


The auto keyword is an unnecessary historical feature of the language.

The other disfavored keywords of the C language do sometimes serve a niche purpose, but have been found to too often create more headaches than value. Specifically, the register keyword presumes the programmer is smarter than the compiler.

Use of any of the keywords goto, continue, and break to create unconditional jumps too often results in spaghetti code.




The presence of these keywords in new or modified source code shall be detected and reported via an automated tool at each build.


I completely agree with the rules discouraging auto and register use. Those keywords had meaning mostly in ye olden times, when compilers needed to be "driven".

However, I find the approach of banning the use of continue and break a bit extreme.

The danger of goto is clear: the potential for an unconditional jump can break any structure of programming (nested loops and multi-level blocks, but also permit jumping in/out the middle of any block) that could ultimately lead to an unexpected behavior, depending on compiler/environment used. Also, use of goto breaks the structured programming paradigm.

The risks with continue and break are more nuanced. Perhaps their use is more a matter of readability vs. the proven dangers of goto. Anyway even readability can be questioned. Removing a break statement may mean adding more control structures or variables, to rephrase the containing loop control statement test condition. I just go figure a while loop with a handful of different break cases can become an overcomplex bunch of nested if statements plus an overgrown multiple test condition.

Personally, I think that continue and break should be suggested as possibly to avoid where they compromise readability but not as to be totally avoided at all.

Note that I do agree with related rule 6.2.c about having only a single return per function.

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.