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. In this chapter from Perl Debugged, the authors come up with some good Perl development behaviors.

"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.

3.1 Beginning

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.