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
goto statement. Still, it was sometimes a real problem not to have, or
goto, precisely because exceptions were not yet available.
With such a view of things in mind, using
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
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