Programming Style: Examples and Counterexamples

Abstract

The following paper by Kernighan and Plauger is one of three chosen from the December 1974 issue of ACM Computing Surveys. It's considerably shorter and less theoretical than the companion papers by Knuth [Paper 20] and Wirth [Paper 13]; indeed, it's less theoretical and more down to earth than most of the papers in this book! For that reason, many readers will view it as a breath of fresh air, and will rejoice at the presence of real FORTRAN examples and real PL/I examples. The paper is largely excerpted from Kernighan and Plauger's first book, The Elements of Programming Style, providing a nice, concise, 21-page summary that you can read in less than an hour. One of the themes of this paper is that structured programming is, in a sense, a secondary issue; the primary concern of programming, according to the authors, is style. The elements of programming style consist of such things as expression (organizing individual statements so that they read clearly), structure (organizing larger blocks of code so that the program hangs together), robustness (writing code that can defend itself against bad data from the outside world), and, finally, efficiency. As I've said, there are examples to illustrate these elements of programming style --- examples that are from the kind of programs that one would expect to find in an actual scientific or business-oriented EDP shop. Indeed, the examples are real, but in a very special sense: Kernighan and Plauger have taken all of their examples verbatim from other programming textbooks. Although the examples don't include any COBOL or assembler code, the enterprising reader can generalize from the FORTRAN examples so as to apply the lessons to his own work. There is one other theme in this paper, one that I think is particularly important in these days of elegant programming languages like ALGOL and PASCAL. Rather than trying to restate Kernighan and Plauger's point, let me quote them directly: . . . many people try to excuse badly written programs by blaming inadequacies of the language that must be used. We have seen repeatedly that even Fortran can be tamed with proper discipline. The presence of bad features is not an invitation to use them, nor is .the absence of good features an excuse to avoid simulating them as cleanly as possible. Good languages are nice, but not vital. FORTRAN and COBOL programmers, take heed!