By: Quinn Slack

April 14th, 2002

Reader Rating: 7

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.

use warnings;

Another similar helpful tool is Perl's built-in warnings. Like the strict pragma, they give you advance warning of any quirks that might or might not be errors, but probably are. Again, just like with strict, you can add them to your program by just adding use warnings; to the top. The top of your code file should now look like this, provided that you want to add both strict and warnings.

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

But what exactly do these warnings do? They will show you your typing mistakes, for instance, if you try to use = instead of == in an if block, or you try to add a string to a number, like print "fish" + 4;. These might seem like silly mistakes, but they're really quite common. If you think about the errors you make when you're debugging, you will find that most of them are "stupid", and that you just weren't thinking right when you were coding that bit.

Wrapping It All Up

Debugging will always take more time than it should. Whether it takes you twice as much time as coding new features, or it takes you just a few seconds every week (lucky thing!), these tips will drastically reduce the time you spend being frustrated as you search for that errant mistake. With the tools that are available, you have no excuse to not use them!

For every mistake you make, think about how you could have prevented it as soon as you tested your code. Automate the bug fixing that can be automated. Let the Perl interpreter do the dirty work, and leave the tough problems and new features to us humans. Programming is about making software, not bugs!

Links

The use strict; documentation, visit http://perlmonks.org/index.pl?node=strict [1]

For more information on use strict; and warnings, visit use strict; is not Perl [2] and Use strict and warnings [3].

[1] http://perlmonks.org/index.pl?node=strict
[2] http://perlmonks.org/index.pl?node=%27use%20strict%27%20is%20not%20Perl
[3] http://perlmonks.org/index.pl?node_id=111088