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
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
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
- Programming by convention
- The Flesh Blanket
- Why you should avoid the . operator
- Elimination of global variables
- 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
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
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.
Back to "MJD in Israel"