You might ask how much could really be said about this. The answer is that you would be astounded.

A few random topics are how you should name variables (chapter 1 of the Camel has some interesting advice for that), how much to indent (anything from 2-4 works as long as you are consistent, Larry Wall uses 4), to how long a function should be (my estimate is that I average about 10 lines, a general rule of thumb is that 50 lines or one screen should be a max), how do you give feedback (it turns out that code reviews are cost effective just in terms of bugs discovered), management techniques, programming methodologies... You name it, it has been studied and frequently useful information is known.

The importance of the topic can be seen in Perl by looking at how many functions exist for little purpose other than to help people keep programs managable. A short list includes bless, local, my, package, require, sub and use. Don't forget the pragmas strict, vars and diagnostics. (And turn warnings on as well!) In addition Perl has quite a bit of syntax (think comments, POD, flexible quoting, etc) that is geared towards letting you say things in a natural way. (There is a school of thought that says that making the gap between how you think about a problem and how you say it small is good. Perl tends this way. There is another that says it is good to always say things in a consistent way. The truth is somewhere in the middle, it depends on the characteristics of the product and developers whether flexibility hurts or helps.) Getting familiar with and using those tools on a regular basis will go a long ways towards helping keep your script managable.

But now I should reveal a dirty little secret.

We do all this, and we still fail. Individually and as a whole, the programming industry routinely fails in both insignificant and spectacular ways. The central problem of programming is the same today as it was 50 years ago. Namely keeping in control of the complexity of software. There is no need to be cynical about research into this problem, we have learned a lot over the years, and we can handle much harder problems now. Your script is quite managable. But still our basic barrier is in our ability to keep track of what the computer has been told to do. We can move where that barrier is, but not stop it from being a problem in the end.

From of this research there is a key insight that comes up again and again. That is the value of modularity. You really want to take problems, and break them up into smaller problems, then produce solutions to each smaller problem, and put the components back together. It is important that each component be independent of the others. This is true whether your components are functions, modules, etc. As a random instance Dominus has a good rant about why this matters. Indeed most of the functions and pragmas that I listed above in some way serve to make it possible to isolate components, or to help you verify that things have been properly separated.

If you want good places to pick up more advice on this topic, tombstone 163 gives links for a number of books, including both Code Complete and The Pragmatic Programmer. Most good Perl books will give practical demonstrations of how to do it. And, of course, look around at this site. There is a lot of good advice, and many monks offer links to even more. I would personally recommend visiting the home nodes for Dominus, merlyn and chromatic for a start.

(Next up, how to write a long post without meaning to!)

UPDATE
Edited to fix minor grammar mistakes.