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:

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:

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.