Perl Program Repair Shop and Red Flags

Prerequisites: Basic familiarity with Perl is required.

You've probably been working too hard when you program, writing twenty lines of code when you only needed ten. But there is a better way, and I will show it to you. You'll learn how to improve your own code and the code of others, making it cleaner, more readable, more reusable, and more efficient, while at the same time making it 30-50% smaller. Smaller code contains fewer bugs and takes less time to maintain.

All the bad code in this class is guaranteed 100% genuine and typical. We will examine several real code examples in detail and see how to improve them. We'll focus on 'red flags', which are obvious warning signs in your code that are plainly visible once you know what to look for, and on techniques that require little complex thought or ingenuity.

Participants are encouraged to submit their own code for anonymous review in the class. Class content varies depending on submissions, but is sure to include some of the topics listed below.

• Families of variables
• Making relationships explicit
• Refactoring
• Programming by convention
• The Flesh Blanket
• Conciseness
• Why you should avoid the . operator
• Elimination of global variables
• Superstition
• The use strict zombies
• Repressed subconscious urges
• The cardinal rule of computer programming
• The psychology of repeated code
• Techniques for eliminating repeated code
• What can go wrong with if and else
• The Condition that Ate Michigan
• Resisting "Holy Doctrine"
• Trying it both ways
  
• Structural vs. functional code
• Elimination of structure
• Boolean values
• Programs that take two steps forward and one step back
• Programs that are 10% backslashes
• print print print print print
• C-style for loops
• Loop counter variables
• Array length variables
• Unnecessary shell calls
• How (and why) to let undef be the special value
• Confusion of internal and external representations of data
• Tool use
• Elimination of repeated code with higher-order functions
• Learning to use a hammer
• The swswsw problem
• Avoiding special cases
• Using uniform data representations

Discussion

Usually I like to provide a class outline on my web site. But a detailed outline doesn't represent this class well because the class is not hierarchically organized. It is structured around a series of examples; the examples suggest certain themes, which I then develop in more or less detail.

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.

• Avoiding 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. Relationships should be explicit wherever possible.

All code is guaranteed genuine---this class contains no contrived or fake examples. Even trivial one-line examples are taken from real code. I don't want to stand up and expound a lot of principles that have nothing to do with the real world. If I couldn't find lots of real examples of the problems I wanted to talk about, I wouldn't put them in the class. The problems I discuss are all problems you will see in real code, because I see them over and over in real code.