The Best of Creative Computing Volume 1 (published 1976)

Page 56 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails

Structured Programming (program display)

graphic of page

shorten the conceptual gap between the static program and the dynamic process,
to make the correspondence between the program (spread out in text space) and
the process (spread out in time) as trivial as possible." This is the source of
the objection to the GOTO statement. The GOTO can lead to a complicated flow of
execution through a program text that can be almost impossible for a human
reader to follow. Work on the formal proof of program correctness as resulted in
some good systematic ideas in program coding. Bohm and Jacopini (1966) proved
the logical superfluousness of the GOTO statement and showed that any problem
could be expressed using the simple control structures of sequential processes,
selection, and iteration. These corresponded to the normal sequential execution
of a program, the IF-THEN-ELSE construction, and the FOR-NEXT or DO
constructions. The inclusion of BEGIN-END blocks lends a simple versatility to
these constructions. Using "structured" coding results in real benefits for the
human reader. it becomes easy to read a program from top to bottom without
having to look back and forth all over the program to pull pieces together. A
simple example in BASIC should demonstrate the strength of these simple control
structures.

10 LET T=0
20 LET T=T 1
30 LET N=NO*EXP(R*T)
40 PRINT T,N
50 IF T 10 THEN 20

20 FOR T=1 TO 10
30 LET N=NO*EXP(R*T)
40 PRINT T,N
50 NEXT T

These two pieces of code perform identical functions. In the first, the
programmer starts reading, has to think about the initialization of T, reads the
next two lines, sees the IF, looks back to line 20, and begins to put it
together. In the second piece of code, the programmer reads top to bottom
without having to stop once. When structured coding is incorporated in a large
program, where there are several levels of control, the improvement in
readability demonstrated above is magnified many times over.

Program Display.

The third level at which we can apply the concept that structure should reflect
function is in the actual display of program code on a page. The visual
structure of the code should convey to the reader as much information as
possible about the functional content of the code. An effective way of doing
this is to uniformly indent FOR-NEXT or DO loops, and to doubly indent nested
loops. The reader who encounters the FOR or DO can then see the extent of the
loop immediately without stopping to scan through to find the end of the loop.
An idea from Weinberg (1971) is to have programming aids for listing programs
that would do various things such as indent loops uniformly, put keywords in the
programming language in boldface, move all comments to the right hand side of
the page, etc. Indenting and the use of white space in vertical spacing should
be used by all programmers. Additional flourishes depend on ingenuity and
available printing mechanisms.

Structured programming, then, is the application and expansion, at several
levels, of the concept that structure should reflect function. The usefulness
and success of structured programming has been demonstrated (Baker and Mills
1973). The reason for this success is that programming is a human activity. When
a program is written the work isn't done. It has to be debugged. As it is used,
more bugs will be found, or it will need to be modified to fit changing needs.
Few successful programs are ever static. Programmers spend the bulk of their
time debugging or reworking program code. Because of this, programs have to be
readable. Since structured programming focuses on clear program organization,
increased information content, and greater readability, it has a striking
effect.

The object of this discussion has been to show how the seemingly disconnected
ideas of structured programming are united by the theme that structure should
reflect function. No attempt has been made to expand the ideas into detailed
discussions or case histories. Those who have a serious interest in programming
should read Dijkstra's articles.

References

Baker, F. Terry, and Harlan D. Mills, "Chief Programmer Teams", Datamation,
December 1973, P. 58.

Bohm, Corrado, and Guiseppe Jacopini, "Flow Diagrams, Turing Machines and
Languages With Only Two Formation Rules" Communications of the ACM, May 1966, P.
366
Dijkstra, Edsger W., "GOTO Statement Considered Harmful", Communications of the
ACM, March 1968, P. 147
Dijkstra, Edsger W., "Notes on Structured Programming", Structured Programming,
Academic Press, New York, 1972.

McCracken, Daniel D., "Revolution in Programming: an overview", Datamation,
December 1973, p. 50.

Miller, Edward F., Jr. and George E. Lindamood, "Structured Programming:
Top-down Approach", Datamation, December 1973, p. 55.

Weinberg, Gerald M., The psychology of Computer Programming. Van Nostrand
Reinhold, New York, 1971.

The author graduated from Dartmouth College in January 1973 with a B. A. in
biology. He has since served as chief programmer for the CONDUIT project at
Dartmouth, contributing to the development of standards for the preparation of
transportable programs. His main interests are ecological modelling and
educational uses of computing.

Page 56 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails