Structured Programming

Structured Programming is a foundation of ModularProgramming and ObjectOrientedProgramming, 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 ObjectOrientedProgrammingLanguages.) (Yes, but it's structured garbage!) (Not necessarily, but it's encapsulated within the object.)

It generally involves:

Avoidance of GoTo'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 StepwiseRefinement (as apposed to say grouping by "objects" or domain nouns.)

"...it just seems like good programming practice to me." -- ChuckMoore, on one of Dijkstra's papers on StructuredProgramming

CeeLanguage/CeePlusPlus 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 SmalltalkLanguage, 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".) -- JeffGrigg

But aren't those forbidden constructs exactly what exceptions give us? Alternatively, aren't most of the justifiable uses of GoTo in CeeLanguage to do with simulating exceptions?

I think the answer is that the one additional structure missing from PascalLanguage is abrupt termination on errors, and exceptions add this. -- MartinPool

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 ExceptionalConditions. 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 AllPanaceasBecomePoison.) -- JeffGrigg

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 "GoTo is bad," the point is that "unrestricted use of go to is bad." -- WayneMack

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.

JacksonStructuredProgramming (JSP) and JacksonStructuredDesign? (JSD) also fall within the structured programming philosophy.

If multiple exits are bad, does this mean we shouldn't use GuardClauses?

Multiple exits aren't bad. This is an old and outdated paradigm. StructuredProgramming, 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.

GuardClauses 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 GoodThing 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 CobolLanguage was EnglishLanguage, paragraphs should be paragraphs. Much like in the newspaper. Try reading that; it was a BadThing.

The idea behind removing GoTos 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++/JavaLanguage/./.. code and tell me it's structured for the human reader.

It should be noted that different people mean different things by StructuredProgramming. For instance DonKnuth famously wrote a paper called StructuredProgrammingWithGoToStatements which argued for where and when GoTo fit with structured programming.

See also Internal Loop Exits Are Ok. (Yeah, tooting my own horn, so sue me.) -- BenTilly

The last bullet point used to read

Multiple entry points to a function/procedure/subroutine. (...which is hard to do outside AssemblyLanguage. ;-)

But it isn't all that hard, actually. FORTRAN (FortranLanguage) and PL/I (PliLanguage) explicitly supported multiple entry points to a procedure, and this mechanism was exploited in early approaches to ModularProgramming (BarbaraLiskov taught her students this technique). Nowadays we use complimentary [complementary?] names like 'PolyMorphism' 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 GoTo commands; this includes a lot more languages than just AssemblyLanguage.

Yes, but the point is that modern interpretations of multiple-entry are an essential piece of current BestPractices. 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 CyberFundamentalism, that says "Stick to the StraightAndNarrowPath, and your code will be without sin."

If you insist that your CodingConventions 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. -- RichardGabriel, quoted from http://java.sun.com/features/2002/11/gabriel_qa.html

See SoftwareEngineeringIsCreative, ProceduralMethodologies.

Also of interest: GoTo, GoToProblem, GotoConsideredHarmful, StepwiseRefinement

CategoryCodingConventions CategoryCodingIssues CategoryJargon ProgrammingParadigm CategoryDataOrientation