About strict. What I was reacting to was your saying you knew about it but couldn't be bothered to use it. If you know about it, know that it is supposed to help, don't use it because you "can't be bothered", and then want help, that is irritating. If you don't know about it, different story. If you don't know how to use it, we should solve that.

Had you said you hadn't figured out how to use it, a dozen people would have given you clear instructions. Had you not mentioned it, people would assume you didn't know about it and tell you about it.

Let me tell you about strict.pm. All that you do is this. In the first 5 lines of the program put:

use strict;
use vars qw( );
[download]

Then proceed to write your program, declaring variables with my as you did. The small number of global variables you have you put into the list you are feeding vars. Like this:

use vars qw( $thing @list %lookup );
[download]

Now as you develop Perl will be able to spot many typos for you.

When should you do this? Well not based on the number of globals in your program (many of mine have no globals at all). Instead it depends on how many lines of code you might accidentally create a global with a typo. A decent rule of thumb is 20 lines. If your program goes over 20 lines, put strict in.

Now why are people so quick to say this? Well TIMTOWTDI, but not all ways are created equal. Through long experience, most of us have learned that fact...

Now about indents. The idea is simple. The indentation on each line should indicate scope. Every time you open a new function, if statement, etc, indent farther. That way just glancing at your code will show the intended logical structure. This makes code much easier to scan, analyze, and makes it possible to figure out many typos. To get an idea what it should look like you can download perltidy and run it on your code.

Trust me. It makes a huge difference.

The value of consistent formatting is not specific to Perl. It applies in all programming languages. An excellent place to learn about programming details like this is the often recommended Code Complete by Steve McConnell. Its examples tend to be in C and Pascal, but the advice is timeless.