IMPLICIT AND EXPLICIT STRUCTURES

Why is it necessary to have methods to reveal structural features of a program? There are two parts to this question:-

1. How do these features get hidden?

2. Why should we bother to reveal them?

The answer to the first is that a program is written in an implementation language, by a programmer (or generated by a code-generation tool). The language itself, may have an inadequate vocabulary or repertoire of constructs to distinguish between important kinds of semantic patterns, or the programmer may not have known or used the full range of appropriate constructs in the language. However many languages (and hopefully programmers) have been upgraded over the last few years, and there are fewer reasons why structural features of newer programs should be hidden through language deficiencies. Examples of language upgrades include COBOL-74 to COBOL-85, FORTRAN-77 to FORTRAN-90, and Kernighan and Ritchie C to ANSI C. Commercial pressures may exist to convert programs from the older versions of a language to a newer version, either because the vendor no longer supports the older version of a language, or because it is regarded as undesirable to support more than one version of a compiler and related language tools. Of course the effort of conversion to a newer version of a language can often be minimized by simply replacing obsolete constructs by the corresponding constructs in the new version of the language, but when frequent and substantial changes to a program are anticipated, it is more appropriate to adopt a more proactive approach.

The answer to the second question, is that there are many programs which may be candidates for substantial planned modification in the near future, and it is reasonable to require that the text of such programs should make it as easy as possible to reason clearly about the their behaviour. That is, the choice of constructs used in the program, and the way the text is presented to the reader should be chosen to make the structure explicit and visible. On seeing such constructs, the reader is immediately prompted to recall the reasoning techniques about such constructs.

Consider a program where a loop is implemented by:-

A test for a condition and a forward GOTO to the end of the loop

The loop body

A backward GOTO to the test

This is executionally equivalent to the loop construct, but the existence of a GOTO will generally create an uncertainty in the mind of the reader, who will have to spend valuable time verifying that a loop is being implemented. If the loop had been constructed using a PERFORM UNTIL construct, then the knowledgeable programmer could immediately enter the mindset appropriate to reasoning or asking questions about loops.

The whole success of the structured programming movement was the realization that a program was not just code to be compiled and executed, but a document to be read and reasoned about by a community of readers. For long-lived programs the members of this community may not know each other, making clarity of presentation of the program even more important. In some cases, the cost of reading and reasoning may well exceed the cost of execution of the program, over its lifetime.

That is, good software requires program texts that clearly signal their important structural properties, and the important structural properties are those that eliminate unnecessary generation of hypotheses about the behaviour of the program, by its readers.