Attack of the Killer Bugs!

Perl is without doubt a very complicated programming language. The tiniest typo can yield an error message that scientists could spend years decoding. However, what most people don't know is that Perl offers facilities that are specifically designed to eliminate the most common errors.

There are thousands of things you can do to squash bugs, but here I'm going to highlight the three most effective tips. You have to be prepared to change your coding style a tiny bit, but it's absolutely necessary that you use Perl's built-in bug-finding features in your code: it's this that separates the beginners from the professionals.

Even if you think your current style is working for you, step back and think about it. Do you spend hours on each bug? Do you dream of squashing bugs in your sleep, only because you don't have time to seek and destroy them all during the day? If so, you're a prime candidate for these tips. Don't simply read this article -- act on it. And if you're a Perl wiz, there's always room for improvement, isn't there?

Choose Your Editor Wisely

Not all code editors are equal. Some are simply text editors, like Notepad. Some incorporate syntax highlighting, but not much else. Some balance speed and amenities. And others seem to suffer from feature overload.

You have to choose carefully. An editor without syntax highlighting will give you a large disadvantage. Syntax highlighting shows whether you've completed parentheses, quotes, and any other types of delimiting characters. Quoting errors are nearly impossible to make with the right editor, but they can plague you if you choose to use Notepad or a similar editor.

Syntax highlighting isn't the only feature you need to look for in an editor. Check for the ability:

• to open multiple files,
• to change fonts,
• to automatically indent, and
• to match braces (to highlight the opening brace when you close a block of code).

The right editor is, by far, more important than anything else when it comes to programming correctly. There are so many possible errors that editors can prevent, that it's pointless to attempt decent code using a program that's outdated or low on functionality.

use strict;

The Perl "strict" pragma, as it's called, is a file that tells Perl to be pickier about your code. A picky Perl will warn you when it sees anything that is potentially an error. You might find that strict prevents you from writing your code the way you're used to -- it'll certainly seem that way at first.

To give your program the benefit of strictness, simply add use strict; to the top, after any #!/usr/bin/perl lines, but before any other code. So your code should look something like this:

#!/usr/bin/perl
# weather.pl by Perl F. Anatic
use strict;

The major rule that strict enforces is the explicit declaration of variables. No longer can you simply start using a variable, as you will now need to tell Perl about it beforehand. This entails using my, as seen below.

my $fruit = fruit_of_the_day();

Normally, this would have been written as the following.

$fruit = fruit_of_the_day();

Why is it advantageous to use this new style? Strict is good because it makes it impossible to misspell a variable name. Well, not impossible, but if you do so, it'll give you a very clear warning, and prevent you from becoming even more confused. Consider the following example, where the second time we use the @input variable, we misspell it.

my @input = <>;
print join(":", @inpt);

See what we did? The Perl interpreter doesn't, that's for sure! It chugs right along through our code, without even the slightest idea that anything is wrong. If we had added use strict; to the top of our Perl code, we would have seen this warning.

Global symbol "@inpt" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

Because every variable has to be declared before use, and we haven't told the interpreter about @inpt, it tells us our error. How much easier could coding be? Without these helpful tips from the Perl interpreter, we could have spent hours searching out the cause of our problems. In a file with hundreds of lines (as opposed to this two-line example), it makes finding your bugs exponentially easier.