Can someone give me "the lecture" on why you shouldn't make all your varables global when programming in perl. I have been doing this but I have heard that it is not a good practice.

From a purely practical point-of-view, it's not so much that globals are bad, as it is that locals are really handy. Say you're in a loop, and you want to do the same function with a different data in each iteration. If you use a local (my) variable to feed data to the function, you're guarenteed that no data from a previous iteration of the loop can pollute a later iteration, if say the variable doesn't get filled every time.

Also, with local variables, you can re-use common variable names like $i for loop iterations and not have to worry about there already being data in the var.

Keeping things local that should be local is a good housekeeping practice.

Technically speaking, using local (my) variables arises from the need of eliminating namespace clashes, but the fact is it has a somewhat unrelated purpose. That is, to make sure the scope of a variable solely depends on the lexical scope only. So you can tell the scope of the variable directly by looking within the current block and nowhere else. Subroutines invoked from within this block will not see the variable. so,

You can tell that the scope of "my $var" is within BLOCK 1 but not to subroutines called inside. So (1) and (3) are 10 and 20 respectively. So which $var did mysub() change in the subroutine? It's the global $var, which is shown in (5) as "4" (2 invocations) after the scope of "my $var" expires. As you can be certain of the scope (instead of depending on the call stack, i.e. the nesting of subroutines that get called), it will be easier to debug when the value goes wrong. Perl also gives you a variant "local" which implements the scope-depend-on-call-stack policy (rare among commonly in-use programming languages today), so (2), (4), (6) are 102, undef and 2. This has a disadvantage that the scope depends on the call stack at runtime so it is more confusing.

If you need to deal with references, you may need to expire a data structure pointed to by a reference at a certain point in the lifetime of the script by controlling the lifetime of the references. If your references are declared as local variables they will naturally go out of scope when the containing block terminates and subsequently get cleaned up. Otherwise, references as global variables will stick around unless you reassign its value. That increases the chance of clashes if you forget to do so.

But bear in mind that Perl global variables are not truly global (see the perlmod manpage), but further subject to the package (a.k.a. namespace) mechanism. Package is the method that addresses name clashes. This is important as we build components that are intended to be reused, so we don't want the $name defined in one component used to clash with another $name in my program. But I'm not going into details of packages here. See the perlmod manpage or relevant literature for details.

This explains why you should try to put your code in modules (at least, in different packages) and use local variables most of the time. Not only this makes your code more reusable, it also helps prevent a lot of problems in the long run as your code becomes more complicated when you try to stick bits and pieces together.

Thanks for the replys. I'll have much better understanding of the importance of using locals.