If your script starts out with something like:

#!/usr/bin/perl -w
[download]

then you will get a (often) helpful warning when you try to use an uninitialized value. And it is usually a very good idea to use that "-w", at least when developing your code.

So, yes, you should initialize your variables before you "read" values from them, just like in other languages.

I think what merlyn is referring to is that, unlike C, Perl will never give you a variable that contains "garbage" values ("random" data that was left on the stack) because you forgot to initialize it. But forgetting to initialize variables is still a common source of bugs (code that works the first time so passes simple tests but fails when used twice in one process, for example), hence the existance of the warning to help you prevent such bugs.

Since we're on the subject of "-w", let's also mention that you should almost always follow that "-w" line with the line

use strict;
[download]

I'll also disagree with coreolyn on the suggestion to remove these precautions once a script is finished for the sake of speed. The speed gain is probably imperceptible. I will agree that removing "-w" can be a good idea since in the production environment you might run into warnings that didn't appear during development and these warning can cause problems in production. I particularly wouldn't remove the "-T" if you used it during development and the script has any security implications (such as a web CGI script). If there are things that "-T" will catch that you didn't find during development and testing, then you probably want those caught once the script is deployed. However, if there are absolutely no security implications with the script and it is very important that the script be resilient, then I'd remove the "-T" before deploying. The "use strict" probably won't find anything in production that it didn't find in development and testing, but I'd leave it in as the risk of forgetting to put it back each time you make changes is probably much greater than the risk that you'd notice the tiny load time.

[ So, should that be "a(n) (often) helpful" or "an (often) helpful" instead? ]

I don't mind being wrong I'm just looking for clarification. If you've already put input checking on all your input, what -T catch that wasn't caught in developement?

coreolyn Duct tape devotee.

Taint mode is like insurance. You may never need it, but it costs so little to keep it in, even after you believe you've tested all the possible input paths. Not only that, but future versions of Perl may decide that new things are leaks, and so your program will (rightfully!) bomb when Perl is upgraded. This has happened already, when all globbing in 5.004 was made "taint-unsafe" because it was discovered that it had always been unsafe to glob because of some bugs in the c-shell.

-- Randal L. Schwartz, Perl hacker

What's also likely to occur is that someone may be working on your script after you (e.g. adding functionality) and has to remember to turn on the -T switch again, which (s)he may not always remember to do, Thus rendering your "insurance"
null & void :)

-- ar0n || Just Another Perl Joe

-- Randal L. Schwartz, Perl hacker

Sounds like your just starting out, and merlyn answered your prccise question. However you should be aware of some conventions you should adopt from the beginning:

1. When developing scripts invoke perl with the -w flag. This will turn warnings on that are visible at compile time that are very helpful at writing clean code.
2. As soon as you get comfortable with Regular Expressions turn on the -T flag. This will put perl in 'Taint checking' mode and will force you to explicitly 'OK' information given to the program from outside the scope of your code (ie input).
3. The other convention that helps to keep variables from getting out of control (Not having to declare variables can make it almost too easy to keep track of the variables scope(s)); is to declare "use strict" near the beginning of your scripts.

I should also add that once your happy with the scripts to take these flags out of the she-bang line for faster execution

A final word of caution: Perl is very addicting