Length: 3-6 hours
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.
The class is different every time I give it---I am always replacing old sections with new ones. Three-hour versions of the class typically consider two to four examples; six-hour versions consider five to eight examples. The best Red Flags classes happen when some of the examples have been contributed by people in the audience.
Six-hour hands-on versions cover two to four examples, and include a development lab, in which the students all write the same program, then a maintenance lab, in which the students exchange their lab programs at random and then extend and debug the once they receive, and discussion sections, in which the students analyze and critique the code.
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.
The Cardinal Rule of Computer Programming.
Course content changes every time I give the class. At present, the class covers:
Other code I've discussed in the past has included:
I'm presently preparing new material that analyzes code written by a well-known Perl expert.
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.
Return to: Universe of Discourse main page | Perl Paraphernalia | Other Classes and Talks
mjd-perl-yak+@plover.com