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

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

1.7.c. It is a preferred practice to avoid all use of the goto keyword. If goto is used it shall only jump to a label declared later in the same or an enclosing block.

1.7.d. It is a preferred practice to avoid all use of the continue keyword.

Reasoning: The auto keyword is an unnecessary historical feature of the language. The register keyword presumes the programmer is smarter than the compiler. There is no compelling reason to use either of these keywords in modern programming practice.

The keywords goto and continue still serve purposes in the language, but their use too often results in spaghetti code. In particular, the use of goto to make jumps orthogonal to the ordinary control flows of the structured programming paradigm is problematic. The occasional use of goto to handle an exceptional circumstance is acceptable if it simplifies and clarifies the code.

Enforcement: The presence of forbidden keywords in new or modified source code shall be detected and reported via an automated tool at each build. To the extent that the use of goto or continue is permitted, code reviewers should investigate alternative code structures to improve code maintainability and readability.


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.