Short "good" programs

We are distressed by the article "The Strange Power of FORTRAN" by Hans Janssens (SEN Vol. 9 , No. 1, pp 50-51). We take issue with the author's underlying premise that a short program is a bette r program (than presumably a longer version). For a number of years, we have been developing computer software within the productio n environment. Our experience indicates that the most important metric (aside from time and space) upon which we should judge the "goodness" of a program is readability. If a program is readable, i t is understandable ; if a program is understandable, it is maintainable ; if a program is maintainable, i t is "good" (as well as perhaps being portable). What disturbs us is not the illustration of FORTRAN' s power to allow writing very compact code, but the unreadability to which compact code ca n sometimes lead. Certainly the code presented by Janssens could be clarified by suitable comments , but we believe that clearer code which requires less commentary explanation is superior. In the present case, we are concerned that the author's view tends to produce programs which, i n being short, contain "clever" or "cute" coding practices. Kernighan and Plauger [1) provided one o f the better examples of cute code, as follows : On a number of occasions, we have asked professional programmers to tell us exactly what this cod e does. Inevitably, if the answer was supplied in less than two minutes, the answer was wrong. If w e supplied the following fragment, the answers were usually correct regardless of the speed of response. In the production environment, taking two minutes to decipher the meaning of a three line cod e fragment is too long. Ask our customers or the maintenance programmers who must follow whic h they would prefer. The production environment is already filled with too many pitfalls to allo w Janssens' contention to remain unchallenged. We have observed that "entry level" programmers tend to view clever code as paradigms fo r emulation. Fortunately for our customers, as well as ourselves, these programmers mature (as d o their coding practices). We do not wish immature programmers to emulate poor coding practices o f the type exhibited by Janssens' example. We therefore are concerned when such practices appear i n SEN .