Structured Programming is a foundation of Modular Programming and Object Oriented Programming, as it's assumed that individual methods are structured (i.e., coded with only #1 to #3 above). (Of course, plenty of people write garbage in Object Oriented Programming Languages.) (Yes, but it's structured garbage!) (Not necessarily, but it's encapsulated within the object.)
It generally involves:
Avoidance of Go To's. Nested conditionals and loops are used instead.
Use of functions or subroutines to break up large sections of code and/or to factor out repeating behavior to a single spot.
Code structuring via Stepwise Refinement (as apposed to say grouping by "objects" or domain nouns.)
"...it just seems like good programming practice to me." -- Chuck Moore, on one of Dijkstra's papers on Structured Programming
Cee Language/Cee Plus Plus programmers often casually violate the rules of Structured Programming in minor ways, and rarely suffer major problems from it, if their programs are otherwise modular or OO. Structured Programming is a non-issue in the Smalltalk Language, as methods are so small that no rational person would use "goto," even if the language supported it. (However, multiple exit points are supported and frequently used in Smalltalk, so Smalltalk programs are rarely "structured".) -- Jeff Grigg
But aren't those forbidden constructs exactly what exceptions give us? Alternatively, aren't most of the justifiable uses of Go To in Cee Language to do with simulating exceptions?
I think the answer is that the one additional structure missing from Pascal Language is abrupt termination on errors, and exceptions add this. -- Martin Pool
I would say that exceptions violate the rules of structured programming. But go ahead and use them: they're a good way to handle unusual Exceptional Conditions. Any program written with exceptions could have been written without them, using only the constructs (#1 to #3) above. But I think the program with exceptions is likely to be more easily understood and maintained by humans. (Like All Panaceas Become Poison.) -- Jeff Grigg
My view is that structured programming is the opposite of ad hoc programming. In structured programming, we shift program control in a very limited, prescribed set of ways. By providing a highly controlled manner in which they operate, exceptions would fit with this concept of structured programming. The point is not that "Go To is bad," the point is that "unrestricted use of go to is bad." -- Wayne Mack
Nassi-Shneiderman diagrams support Structured Programming, but they do not enforce it. Chapin charts were created to enforce Structured Programming where forbidden constructs are impossible to express.
Jackson Structured Programming (JSP) and Jackson Structured Design (JSD) also fall within the structured programming philosophy.
If multiple exits are bad, does this mean we shouldn't use Guard Clauses?
Multiple exits aren't bad. This is an old and outdated paradigm. Structured Programming, taken to an extreme or pure is some of the nastiest code I've ever had to read. It's amazing what people will do to avoid a perfectly reasonable break or early return. JMTC.
Guard Clauses do not require multiple exits; they can be implemented either way. [Note: This is merely intended as a clarification of guard clauses and does not imply a position regarding multiple exits.]
As with everything, good ideas are quickly perverted. The need for structured programming stemmed from the total lack of understanding of visual processing at the time. Providing visual structure to your code is a Good Thing that will speed up development and maintenance. Indentation and color highlighting are two examples.
A shop a friend of mine had a manager ('way back in '70s) that thought that since Cobol Language was English Language, paragraphs should be paragraphs. Much like in the newspaper. Try reading that; it was a Bad Thing.
The idea behind removing Go Tos was that there is no visual (untextual) cue as to where you're going.
And just because a language is syntactically structured, doesn't mean code for it is visually structured. If we are truly more concerned about human legibility than machine input, then all code should be very pretty and properly indented. Look at a lot of C/C++/Java Language/./.. code and tell me it's structured for the human reader.
It should be noted that different people mean different things by Structured Programming. For instance Don Knuth famously wrote a paper called Structured Programming With Go To Statements which argued for where and when Go To fit with structured programming.
See also Internal Loop Exits Are Ok. (Yeah, tooting my own horn, so sue me.) -- Ben Tilly
The last bullet point used to read
Multiple entry points to a function/procedure/subroutine. (...which is hard to do outside Assembly Language. ;-)
But it isn't all that hard, actually. FORTRAN (Fortran Language) and PL/I (Pli Language) explicitly supported multiple entry points to a procedure, and this mechanism was exploited in early approaches to Modular Programming (Barbara Liskov taught her students this technique). Nowadays we use complimentary [complementary?] names like 'Poly Morphism' and 'overloading' for this sort of thing, but that's all that methods are: multiple entry points into the same (virtual) procedure.
Multiple entry points can be done in any language that supports labels and Go To commands; this includes a lot more languages than just Assembly Language.
Yes, but the point is that modern interpretations of multiple-entry are an essential piece of current Best Practices. To repeat what was written in the discussion about multiple exit points, structured programming is an old and outmoded paradigm. It is a kind of Cyber Fundamentalism, that says "Stick to the Straight And Narrow Path, and your code will be without sin."
If you insist that your Coding Conventions follow the rules of structured programming, you reveal yourself as a martinet who sees rules as a way to crush independence and creative thought, rather than as tools to improve productivity and foster effective communication.
There is little advantage to "independence and creative thought" in the ordering of program statements. It is much better to be independent and creative in the solution of user problems.
Writing software should be treated as a creative activity. Just think about it: the software that's interesting to make is software that hasn't been made before. Most other engineering disciplines are about building things that have been built before. -- Richard Gabriel, quoted from java.sun.com 
Also of interest: Go To, Go To Problem, Goto Considered Harmful, Stepwise Refinement
Category Coding Conventions Category Coding Issues Category Jargon Programming Paradigm Category Data Orientation
See original on c2.com