# Break and Continue in Structured Programming?

One of the ways to ensure following the structured programming paradigm is by having all control flows having only one entry and one exit point. Does skipping iterations by using break and continue in languages like Java count as a second exit point (like a GOTO-statement) or not?

I am aware that Java has no (working) goto statement but a break and continue. The question was whether using them violates the structured programming paradigm or not, i.e. is it bad code style or not (in all languages having break and continue, not just Java).

## migrated from stackoverflow.comDec 20 '14 at 3:39

This question came from our site for professional and enthusiast programmers.

That of course depends on how exactly we define structured programming. We can look to the research papers that coined the phrase, such as the 1966 Structured Programming Theorem. Structured programming, as defined in these papers, would not permit partial execution of a loop body, and therefore neither a break, continue, return or throw statement (nor any exceptions thrown by the JVM).

All of these language features were invented after structured programming, and to address perceived deficiencies of structured programming (in its original definition). Whether these amendments comply with the spirit of structured programming (or equivalently, whether a modern definition of structured programming should encompass these features) has been the topic of some debate, see for instance the 1995 paper Loop Exits and Structured Programming: Reopening the Debate.

Personally, I find applying this 1966 programming technique, ground breaking as it was at the time, verbatim to a modern programming language such as Java an undertaking of very questionable benefit, not the least because structured programming (in its original definition) does not permit exceptions, but exceptions are an integral part of the Java language.

There are probably many accounts of what structured programming is or should be, besides the good historical references and account provided in meriton's answer. But none of this should be perceived as mathematical definitions that should be strictly obeyed by programmers. Some of it may have been tightly formalized for the purpose of proofs that a given style has some good (or bad) properties, such as the Boehm-Jacopini theorem. But that does not imply that such formalization had to be strictly followed in practice, or even had that much impact on the programming community.

Now, the spirit of the structured programming, in the sixties and (early?) seventies was mainly to introduce some kind of organization and readability in a very messy programming world. It never was a tight set of rules to be strictly obeyed, even when some authors did give their own sets of rules to suggest a proper style.

At the time, few people understood how to organize programs around data structures. Programming was more centered around control flow, as programming was perceived as giving orders to a computer. It was common practice to first draw a flowchart, with arrows in all directions, and then translate it into (spaghetti) code, with labels and goto statements to implement the arrows of the flowchart. Structured programming was a reaction to this disorganized practice, and an important concept became the block of statements, or the compound statement. Basically, a program was obtained by composition of such well defined structures, that were to be entered and exited in well identified places. Exceptions as a programming concept were not yet clearly understood and were (part of) the topic of PhD dissertations). The purpose was mainly to do away with the disorder permitted by the use of the goto statement. Still, it was sometimes a real problem not to have, or use, the goto, precisely because exceptions were not yet available.

With such a view of things in mind, using break and continue in loops is a very disciplined use of loops that would have been considered quite acceptable for structureed programming.

This can be put in relation with the use of static scoping. The goto was bad because it created disorder in the control structure, and you never knew how control structures where entered, where control came from after passing a label, or how a statement could be exited (it could even be hidden in a subprogram, since a function could be exited with a goto, which also allowed a poor man's exception), which made programs hard to read, understand and maintain. Dynamic scoping had a similar problem with the role of identifiers, since the meaning of a free identifier in a function could depend on were the function had been called (many possible places), as opposed to static scoping where it depend only on where the function was declared (only one place). Both were intended to easily identify key points in the program structure, rather than have them duplicated and spread all over the program.

In a way, structured programming was for control what OO programming was later for data. But there is still no unique model of OO programming, and there is no reason to expect more regarding structured programming.