Atrocious Programming Thrives

by Conrad Weisert
© 2003 Information Disciplines, Inc., Chicago

NOTE: This article may be circulated freely as long as the copyright notice is included.

Related articles on this web site:

originally published here

What's Happened to Quality Assurance?

Repetition: The #1 Enemy of Program Quality

originally published in ACM SIGPLAN Notices

Comment on Poor Practice in Coding Examples

Pseudo Object-Oriented Programming Considered Harmful

The 1960s

When I was working at Union Carbide in the mid-1960s, I came across a number of examples of program code that were so unbelievably bad that I could barely believe my eyes. I started a file folder labeled "PROGRAMMING: ATROCIOUS EXAMPLES". One of the first listings I put into it was this 24-line COBOL horror:

            IF CURRENT-MONTH = '01'
               MOVE +1 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '02'
               MOVE +2 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '03'
               MOVE +3 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '04'
               MOVE +4 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '05'
               MOVE +5 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '06'
               MOVE +6 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '07'
               MOVE +7 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '08'
               MOVE +8 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '09'
               MOVE +9 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '10'
               MOVE +10 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '11'
               MOVE +11 TO MONTH-NUMBER IN TRANSACTION
            ELSE IF CURRENT-MONTH = '12'
               MOVE +12 TO MONTH-NUMBER IN TRANSACTION.

From time to time I used this and other folder contents as handouts in programming courses. Even beginning students chuckled and were amazed to learn that the author was a business applications programmer of nearly 10 years experience who was highly respected by his user community as a man who "got the job done".

Occasionally someone in the class, usually a manager, would object. "Why fret about elegance if the program works" they might opine. In later courses I altered the handout, changing '09' to '08', to see whether the students spotted the error and if so, how long it took them. After realizing the number of test cases you'd need to validate such code, everyone eventually agreed that

           MOVE CURRENT-MONTH TO MONTH-NUMBER IN TRANSACTION.
is not just more 'elegant' but much more efficient and a whole lot less error-prone.

Expert-Level Offenders

In 1974 two staff members at Bell Telephone Laboratories published a remarkable little book:

Brian Kernighan and P.J. Plauger: The Elements of Programming Style, McGraw Hill, 145 pages, ISBN 07--34199-0.
It consisted of examples of bad programming style followed by Kerhighan & Plauger's rewritten versions. What made the $2.95 (!) book notorious was the source of the bad examples. Their preface explained:
"A word on the sources of the examples: all of the programs we use are taken from programming textbooks. Thus, we do not set up artificial programs to illustrate our points – we use finished products, written and published by experienced programmers."

Kernighan & Plauger weren't setting out to embarrass their author colleagues. They, like many of us, were concerned that the first programming examples impressionable students might see would lead them into extremely destructive habits.

We were also concerned because many of those offending authors were Computer Science professors. How could we expect students to emerge from a C.S. curriculum as competent programmers when their mentors wouldn't make it themselves?

We also began wondering about the internal review and editing process in certain major publishing firms. Discriminating professionals lost their trust in "brand name" textbooks, while their younger naive colleagues continued to buy, read, and presumably be influenced by them.

The Structured Revolution

We hoped that the near-universal embrace of structured programming in the early 1970s would put an end to the spread of bad programming. Everyone in the world now understood, we thought, enough fundamentals of good programming style to avoid the worst excesses of bad practice.

We were soon disappointed.

Interpreting "structured programming" in the extremely narrow sense of just structured coding, students, experienced practitioners, instuctors, and authors continued to produce examples for my file of atrocious examples. When challenged they defensively pointed out that they had followed "the rules". Indeed, even the horrible example that began this article conforms to the flow-control constraints associated with structured coding.

It's Getting Worse!

After a quarter-century of learning, practicing, and teaching structured techniques, we find that the rate at which we come upon candidates for the atrocious folder has not tapered off. Many of today's examples claim to be "object-oriented", "component-based", or some other modern category. It's likely that as much bad code has been written in Java as was ever produced in COBOL. Some recent examples have been the end-product of case studies or demostrations of so-called agile methods, and I fear that we'll see that source produce a steady stream of really awful programs.

Indeed, I've stopped updating the folder, partly because it had become too fat and partly because I know I can easily find plenty of new examples whenever I need them. I've also stopped responding to bad programming practices when I come upon them in a professional or trade journal, except in one situation. That's when the author's purpose was not to show program code incidental to some topic but rather was to enlighten readers on his view of programming style or methodology itself.

I felt that the two SIGPLAN Notices pieces cited at the top of this article were urgently needed to counteract the impact of some particularly damaging bit of silliness. In most such cases, however, I just correspond privately with the author by E-mail, hoping that he (so far they're always male) will see the light and amend his own contribution. Most of those authors respond cordially and do, in fact, eventually retract the worst aspects of their views. (Remember Weinberg's "egoless programming"?) A few, regrettably, take criticism, even mild suggestions, as a personal attack, and become too defensive to engage in useful discussion.

Good programming practice is far from dead, but it's being swamped or at least threatened by outrageously sloppy, careless, or unenlightened programming at all levels. I shall continue to speak out against published atrocities, and hope you'll join me.

An Awkward Incident

Last year a student in a course in advanced object-oriented programming for electrical engineers turned in a homework assignment that violated practically every principle of good programming practice that we had been studying. Since the program ran, I assigned a grade of C-, and returned to the student a listing laced with comments pointing out the numerous appallingly bad practices.

That would have ended the matter for me had the student not shown up at my office to complain and argue about his grade. In the course of discussing the work, it became clear that the student couldn't explain why he had made certain choices and didn't really understand the program he claimed to have written. Naturally I suspected plagiarism, and I was right. The program turned out to be an instructor's handout from another programming course in the same university.

Needless to say, that instructor had distributed the material as a good or recommended problem solution. I thus not only had to confront the distasteful plagiarism issue, but had also managed to inform a student that his earlier instructor, a full-time tenured professor, was incompetent in computer programming.

Fortunately, neither I nor, as far as I know, the offending student told anyone else.

Return to IDI home page

Last modified January 9, 2003