Structured Programming is a foundation of ModularProgramming
, 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 just seems like good programming practice to me." -- ChuckMoore
, on one of Dijkstra's papers on StructuredProgramming
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".)
But aren't those forbidden constructs exactly what exceptions give us? Alternatively, aren't most of the justifiable uses of GoTo
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
's Diagrams support Structured Programming, like a FlowChart
where forbidden constructs are impossible to express. (NewSpeak for programmers. ;-)
(JSP) and JacksonStructuredDesign?
(JSD) also fall within the structured programming philosophy.
If multiple exits are bad, does this mean we shouldn't use GuardClause
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.
s 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
, paragraphs should be paragraphs. Much like in the newspaper. Try reading that; it was a BadThing
The idea behind removing GoTo
s 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
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 BestPractice
s. 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
Also of interest: GoTo
CategoryCodingConventions CategoryCodingIssues CategoryJargon ProgrammingParadigm