BMaximus, you have a high sense of self-integrity to question your own design so well. The skill (art) of organizing a project is unique to each person. What I have found is that regardless of OO vs. structured approaches the program is a state machine.
Example:
- What is the startup state of the script, environment variables, internal variables
- How does the script leave startup to a running state
- How does it handle signals and exceptions, not in the normal flow - what state does it go to and then leave on exception
- What inputs drive the script to what new states - like reading lines in a file, processing each line, looking for EOF, scanning for input errors
- Are errors handled gracefully
- How does the script terminate - what does the terminate state do
I once had to write a text restructuring program that had three variables with two states each for a word processor ruler function. It wouldn't translate ceratin content right. Then I realized that the scanner had eight states (two to the third power) but I had only coded for six. Me dumb. Twenty minutes of new code and she shebanged. So.. are all of the states accounted for in YOUR code.
Also on the advice from above, use the simplest means you can employ to get it done.
Also, I usually prepare by writing psuedo code-like comments. The stunning wonder of Perl is the move from the psuedo code to the Real Thing is so short. Sometimes I draw state diagram pictures, especially if I have to explain it to others.
-diskcrash
