On the composition of well-structured programs

  • Authors:
  • N. Wirth

  • Affiliations:
  • -

  • Venue:
  • Classics in software engineering
  • Year:
  • 1979

Quantified Score

Hi-index 0.00

Visualization

Abstract

Wirth's "On the Composition of Welt-Structured Programs" is one of three papers selected from the December 1974 issue of ACM Computing Surveys. Together with Knuth's "Structured Programming with go to Statements" [Paper 20] and Kernighan and Plauger's "Programming Style: Examples and Counterexamples" [Paper 19], it provides an excellent overview of the whole subject of structured programming and top-down decomposition of programs. While the paper may be a little too theoretical for the average reader, the examples given by Wirth are extremely instructive. For example, after four pages of a delightful philosophical review of the dismal state of the art of programming, Wirth launches into examining a total of five sample programs --- all involving an ALGOL-like pseudocode that will be somewhat unfamiliar to the average COBOL programmer, and all involving applications that he wouldn't care about. If you're a COBOL programmer, all I can say is, be patient! Spend the time to read through the examples and to study the code that Wirth presents; it really is worth the effort. For example, one point comes through very clearly after reading Wirth's third, fourth, and fifth examples: "mechanical" translations of an unstructured program into a goto-less program usually will result in clumsy code. Another lesson we learn from reading Wirth's examples --- and one that appears in the other two papers selected from the same issue of A CM Computing Surveys --- is that a piece of program logic often needs to be rewritten three or four times before it can be considered an elegant, professional piece of code. Most programmers violently object to this concept, even though they are quite happy to revise and rewrite a narrative English document three or four times before they are satisfied with its style. The objection to revising program logic in order to improve the style usually is related to the amount of time it takes. In fact, revising program logic usually takes relatively little time, and the vastly improved program can be maintained at a considerably lower cost. If you manage to stick with Wirth through his examples, you'll find his concluding remarks about structured programming a true delight. As he says, " . . . the method of stepwise decomposition and refinement of the programming task automatically leads to gato-free programs; the absence of jumps is not the initial aim, but the final outcome of the exercise." And that says it all!