I have gradually arrived at a quick and dirty "get something up and running" system.

I break the task down, often something like:

get_input();
process_input();
output();
[download]

Each sub would have its own script which would read its input from disk, call the sub and then write its output to disk ready for the next sub. If the input/output is large scripts can be written to validate/produce reports.

The same process maybe repeated with each task depending on complexity or if I'm stuck. In these cases there can be a string of scripts testing quite short subs.

When there is reasonable confidence in the parts it is a case of fitting everything together.

This way I can convince myself that I have some working code with only a small bit that doesn't work rather than a lot of code that doesn't work at all. :-)

It's entirely conincidental that when you're _really_ stuck you have a shortish piece of code, some test input data and, perhaps, an example of the output you need. Very handy if you ask the monks for help!

I have some arbitary rules of thumb:

• Everything must fit on a screen. Subs, loops, if/else blocks.
• Use subs to avoid deep indenting rolling across the screen.
• No hard coded data - at all. Use a config file.
• Use a look up table even if most of data is the same or undef.<.li>
• Don't sweat over arbitary rules of thumb

Later on down the line you can go back over it and reduce the number of subs.

Update

Oh yes, if there is an and an or and a not on the same line the code is just plain wrong. Rewrite it because you'll (me, at least) never ever get it right. :-)