"It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories
instead of theories to suit facts."
-Sherlock Holmes in A Scandal in Bohemia, by Sir Arthur Conan Doyle
As you can tell from the chapter title, we're not above coining horrible neologisms to save space. (When our publisher pays us by the word, we'll be happy to be more verbose, but paying us by the word would be as sensible as measuring programmers' performance by how many lines of code they write.)
Antibugging describes a set of programming techniques that minimize the probability of introducing a bug to a program at design time or input. You could also call it defensive programming. We're applying the principles we developed in the previous chapter to come up with some good Perl development behaviors.
Before you turn your ideas into code, describe them in natural language.
If you can't say it in natural language, you won't be able to say it in Perl.
The Extreme Programming methodology (mentioned in more detail in Chapter 6) is helpful in this respect in that by insisting that tests be written before the code they test, and requiring programming in pairs, it encourages this kind of conversation.
I've seen this too many times: someone is having horrible difficulties doing an exercise and the code is bleeding all over the screen. Yet when I ask them to describe how it's supposed to work, they can't articulate it. This is a large clue that the approach wasn't completely thought out to begin with.