The road to cleanliness (no shower cap required)

If you miss the lint tool, and the "-Wall -pedantic" compiler switches from your gcc glory days, there is hope.

Use the "-w" flag to tell the Perl interpreter to turn warnings on (similar to the C compiler "-Wall" option, but also applied during runtime, not just during the compilation phase). You can do that by adding the "-w" switch to the interpreter invocation line -- usually the first line of the script in a UNIX environment, and a command-line switch in other environments. Some programmers feel that warnings are only for developers, and that the final product should not have warnings enabled.

First of all, there is no final product in programming. As the famous quote attributed to Jack Cohen goes, "a special word for stable is dead."

Second, the warnings will indicate to a user that something could be wrong, and that pre-emptive action should be taken.

Third, using warnings only during the development cycle is like doing fire drills with real extinguishers, then using paper cups to douse the real fire. It simply doesn't make sense to take away that safety net at an arbitrary point in the product development cycle.

The "use strict" compiler pragma (see the "perldoc strict" and "perldoc perlmodlib" manual pages) is somewhat similar to the C compiler "-pedantic" switch. The "perldoc strict" command will tell you more about that pragma. The most important thing about the "use strict" pragma is that it requires that all variables be defined before they are used. The following example illustrates what "use strict" hopes to avoid:

$this_variable_name_is_too_long = 1;
while (
)
{
 $this_variabel_name_is_too_long++;
}

The error never gets noticed until it is a bug. With "use strict," the above would have never compiled. Instead, the following would have had to be written:

my $this_variable_name_is_too_long = 1;
while (
)
{
 $this_variable_name_is_too_long++;
}

The wisdom of using long variable names at all is... well... let's just say that if you have to type more than 15 characters for a variable name, you are probably doing something wrong.

Do not use functions to define constants. While that was necessary at one point in Perl, it is now done with the "use constant" pragma. In the following example, note the comment style and the arrow alignment as well. Visually pleasing code shows that the author crafted every line of code with care. Some editors (Emacs for instance) can do this sort of alignment automatically.

use constant CHILDREN => 3;             # 3 children per process
use constant PI       => 3.14;          # 2 digits of precision
use constant MESSAGE  => "Hello";       # a message

Prototype your functions before they are invoked. It's easy to prototype a function. The "perldoc perlsub" manual page will help you with understanding prototypes better. Prototyping is a good practice for any programmer, because it shows forethought and helps avoid compiler errors in certain cases. It can be tedious to change prototypes as a function changes, but the problem there is that the function was not well-defined from the start. Plan before you code, and think before you plan. Every 10 minutes spent thinking about the path your code will take will save you an hour of coding and debugging.

Perl converts between strings and numbers automatically. There is no way or need to turn this feature off, but novice Perl programmers can create new exciting bugs with it in a matter of hours. Read the Perl FAQ (see Resources), the Programming Perl or Learning Perl books, and of course the "perldoc perldata" manual page ("Scalar values" section).