Repetition: the #1 Enemy of Program Quality

Object-orientation hasn't put an end to atrocious programs

© Conrad Weisert, Information Disciplines, Inc., Chicago
10 November, 1999

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

The principle

In any classroom discussion of program quality one of the first criteria non-beginner students mention is localization. They understand in principle that each value, property, characteristic, or pattern in the program should appear in one and only one place. But how well do they practice that principle in their programming assignments?

Almost all students and practicing programmers routinely manage localization of values (sometimes called parameterization), avoiding so-called "hard-coded constants", using C's #define or const or the equivalent facility in another language. A surprising number, however, continue to turn out extremely repetitive patterns of procedural code.

I noted back in February a special case of the repetition problem: Using the switch . . case construct where a simple table would do.


In a formal course with homework assignments, we have to give the students feedback on the quality of their coding. In particular, a problem solution with unnecessary code repetition cannot earn an A. (See my grading policy for academic courses.)

In a professional setting, we need to give similar feedback through walkthrough discussions or quality assurance reviews, even though we don't assign a grade.

I sometimes put on an examination a particularly atrocious example like the one at the end of this article and ask the students to simplify it.


I occasionally run into a student or an experienced programmer who stubbornly defends repetition. He (so far all of them have been male) may point out how easy it is to paste lines of code using a modern editor program. I suspect that some naive students and programmers harbor a misguided belief that program size is a virtue. A 500-line program is so much more impressive than a 75-line program.

Alas some bosses and even some instructors do reward lines of code or at least fail to object to unnecessary repetition. I often find that students who argue this point took previous courses from instructors who awarded A for any program that worked.

Java obstacles

Although we see unnecessary repetition in programs written in all programming languages, it seems to be especially common in Java programs. That's hardly surprising, given not only Java's hostility to some of the most useful localization techniques, such as macros and text inclusion, but also the demand for poorly-trained Java programmers. (See The Dark Side of Java for a discussion of Java's obstacles to program maintainability.)

The following horrible C example was taken unchanged from an application developed by a contract development firm claiming top skills in object-oriented technology. Of course, I've seen equally atrocious examples in COBOL, Fortran, BASIC, and assembly languages; the depressing thing is that I'm seeing as many today as 25 years ago!

	#include <string.h>
char stuff[15];
char spi1 [15];
char wrk_area[15];
int xx, yy;

void get_stufcti() // Convert number and stick in buffer
xx = 0;
yy = 3;
while(xx < 15)
{if ((wrk_area[xx] == '0') &&
(yy > 0))
{stuff[yy] = '0';
++yy; }
if ((wrk_area[xx] == '1') &&
(yy > 0))
{stuff[yy] = '1';
++yy; }
if ((wrk_area[xx] == '2') &&
(yy > 0))
{stuff[yy] = '2';
++yy; }
if ((wrk_area[xx] == '3') &&
(yy > 0))
{stuff[yy] = '3';
++yy; }
if ((wrk_area[xx] == '4') &&
(yy > 0))
{stuff[yy] = '4';
++yy; }
if ((wrk_area[xx] == '5') &&
(yy > 0))
{stuff[yy] = '5';
++yy; }
if ((wrk_area[xx] == '6') &&
(yy > 0))
{stuff[yy] = '6';
++yy; }
if ((wrk_area[xx] == '7') &&
(yy > 0))
{stuff[yy] = '7';
++yy; }
if ((wrk_area[xx] == '8') &&
(yy > 0))
{stuff[yy] = '8';
++yy; }
if ((wrk_area[xx] == '9') &&
(yy > 0))
{stuff[yy] = '9';
++yy; }
if (yy == 6) xx = 15;
stuff[yy] = '\0';

Those 50 lines can be reduced to about a half-dozen lines of code, depending on how much error checking you want to include.

Return to IDI Home Page
Last modified November 10, 1999