To quote another node: Re: Silly code reviews and shift

• code should be as simple as it needs to be be and no more so.
• code should be as efficient as it needs to be and no more so.
• code should be as readable as it needs to be and no more so.
• code should be as reliable as it needs to and no more so.
• code should fulfil its technical design brief.

Everything comes at a cost. Writting generic flexible code often (but not always) increases it complexity. You have to look at it with a critical cost/benifit eye. Are you likely to need to reuse this code. If the answer is yes there are other applications for this code, then you are probs best off writting a module and pulling the generic stuff out. If the answer is no then write the code to be as maintainable as possible. Look at the points I have bulleted above, consider your priorities and code to those.

Re reading your question, I seem to detect a query about how to split up your code. How much to put into subs and how much in the main body. Asside from obvious sub candidates to prevent code duplication; consider the following. A technique often used is to write pseudo code in terms of comments. Then replace each comment with a block of code. I then look at each block of code and consider how valuable the comment is. Does the code describe itself such that the comment is not required, if it does I leave it alone. If the comment is still required then I would move the code to a sub to simplify the main block. This pulls out complex code, allowing for nice partitianing and easier maintenence. I then apply a similar process to all subs.

Consider as a rule of thumb not allowing any sub to contain any more code than you can fit onto your screen at a time. Consider the 'main block' as just another sub.

ALWAYS KISS ;-)

UPDATE
Having strolled about pm I noticed:

• When do you function? tilly's post is excellent ++
• Standards for Writing Subroutines

These provide some different advice and may be of interest.
HTH
--

Zigster