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
- 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
- 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.
Universe of Discourse main page |
Perl Paraphernalia |
Classes and Talks |
Program Repair Shop Main Page