Perl Program Repair Shop and Red Flags I

Usually I like to provide a class outline on my web site. But a detailed outline doesn't do represent this class well because the class is not hierarchically organized.

I typically cover two to four real programs and work them over in detail, pointing out the problems and showing how to fix them. Some problems appear early on and then recur in other programs so that the class builds up several themes simultaneously. Major themes include:

• Using less code to do the same tasks. Most programs are horribly overwritten. Using less code means that there's less to maintain and less opportunity for bugs.
• Preventing superstition. Many programmers seem to forget that programming is an engineering discipline. They put in code that they don't understand because "I wanted to be on the safe side," or "Bob said I should always do that," or "I heard that sometimes it would break if I did it the other way." There's nothing wrong with being on the safe side, but throwing salt over your shoulder won't help.
• Avoiding repeated code. Many programmers use a cut-and-paste method to generate code. This almost always creates maintenance problems---someone needs to change the code, but they forget to change the other two copies that are elsewhere. Repeated code imposes a maintenance and administrative cost that is far out of proportion to its value.
• Recognizing and minimizing structural elements. Code can be classified into structural and functional elements, just as architectural elements can. Structural elements are those which do not advance the real-world goal of the software. They cost as much as functional elements, but provide no direct benefit. As in architecture, structural elements should be minimized.
• Avoiding purely conventional relationships. When program elements are related purely by a naming or other convention, the maintenance programmer has one more thing to remember, and code becomes complicated or repetitive because the language hasn't been informed of the relation between the elements. Relations should be explicit wherever possible.
• The Cardinal Rule of Computer Programming.

Course content changes every time I give the class. At present, Red Flags I covers a utility for merging reports together, a program for doing recursive directory copy, and a large collection of assorted fragments. Red Flags II covers a utility for cleaning up an upload directory, a program to alter the format of a bio-informatic data file, and a CGI tic-tac-toe program. Other code I've discussed in the past has included a CD jukebox interface program, a program for extracting unique records from a log file, and a collection of examples of how if-else blocks can go wrong. I'm presently preparing new material examining a function written by a famous Perl expert.

All code is guaranteed genuine---no contrived or fake examples. The problems I discuss are all problems you will see in real code, because I see them over and over in real code.

Return to: Universe of Discourse main page | Perl Paraphernalia | Classes and Talks | Program Repair Shop Main Page