The Best of Creative Computing Volume 1 (published 1976)
Structured Programming (structure should reflect function)
Structured Programming
By Christopher G. Hoogendyk
“That's a great deal to make a word mean,”
Alice said in a thoughtful tone.
“When I make a word to a lot of work like that,"
said Humpty Dumpty, "I always pay it extra."
Lewis Carroll
Through the Looking- Glass
A lot has been said about structured programming. You might ask, "Why another
article?" The answer is that no paper yet has pulled together all the ideas and
showed their connection (McCracken 1973). If you ask the average programmer what
structured programming is, he will reply with a collection of rules and
regulations about top-down planning, avoiding GOTOs, and formatting code on a
page. Such a collection of rules is hard to remember and easily misused.
There is also disagreement and confusion about when a program can be called
"structured". A programmer might say he has a structured program and a dozen
others will disagree. Further, as programming theory develops, better methods
will be used and the definition of "a structured program" will change. Let us
throw out the idea of a structured program versus an unstructured program and
look at programs as fitting into a spectrum determined by the skill of the
programmer, the effort he puts into the program, themlanguage facilities, etc.
In these terms we would speak of a well structured program. If Dijkstra put his
best efforts into designing and writing a particular program in the best Algol,
we might look upon it as an extremely well structured program. But, but not
drawing a dichotomy, we also admit that an average programmer can apply the
ideas of structured programming in the language at hand and come up with a
reasonably well structured program. There is no reason to develop a powerful
conceptual tool for programming and then deny its use to a wide range of
programmers and applications.
Structured programming, then, deals with the design and writing of well
structured programs. Now, what is the central theme of structured programming?
If you can't identify a central theme and show the connection between it and
each rule, then most programmers (like me) will see structured programming only
as a disconnected collection of rules and regulations. This failure to pull the
ideas together will be reflected in the use and misuse of the ideas behind
structured programming.
The central theme of structured programming is that structure should reflect
function. This is a powerful design concept. It was the theme of Frank Lloyd
Wright’s architecture. When applied to programming this concept leads to
worthwhile results on three different levels: design, coding, and display.
****
Program Design.
The first level is the planning or design of the overall program. A program
should not be a black box that is patched together until it works. It should
represent a systematic development of the ideas behind the program. This idea
has been carefully developed and presented in case histories of program design
by Dijkstra (1972), and has come to be known as top-down program design. The
practical application of top-down design in program development projects is
discussed by Miller and Lindamood (1972). Very briefly, top-down design means
starting with a definition of the program's purpose and progressively
decomposing it into subactions until you reach a level of description that can
be coded directly into the programming language you are using. There are some
key ideas that emerge from top-down design which are often expressed
independently. One is that you shouldn't bind yourself with an early decision
about particular program or data structures. This leads to greater flexibility
in program design, and makes it easier to modify the design or the program
itself if the requirements are changed. In its simplest form this means that a
variable name should be used in the place of a recurring constant (this is
called parameterization). Thus, instead of referring to device number 3 in your
program, you would refer to the INPUT device. Then, at run time, INPUT could be
initialized to 3. Dijkstra (1972) gives some more instructive examples.
****
Program Coding.
The second level at which we can apply the concept that structure should reflect
function is in the actual coding. This was first expressed by Dijkstra (1968),
although the ideas have been around a while longer. Dijkstra pointed out that
the real subject of programming is the process that results from the run time
execution of the program. He said, "We should do our utmost to
[Image]
