in reply to Re: Lots of subs in large program vs lots of small programs
in thread Lots of subs in large program vs lots of small programs

tilly's comments ++. I just want to add my personal experience here -

I find that the easiest way to decide what should be a subroutine and what should be a separate module is by drawing a system diagram.

First determine the logical functional units that the system is composed of. Then draw a system diagram that shows the interaction between logical function blocks. A diagram is better than a thousand words. Before I proceed on a large project, I always draw lots of system diagrams and flowcharts to help me visulize the system. Design deficiencies can be spotted quite easily.

Rule of thumb for designing a good system:

1) Minimum cohesion. Design your functional blocks so that they have minimum cohesion between them. In other words, minimise interaction between modules at the same level.
2) What the subroutine does can be described by one sentense with out the word 'and' or 'or'... In other words, a clearly defined single task for each subroutine.
3) Keep the size of a module to less than a few pageful.

There are plenty of good references and books on good software design practise. I find the following link on software design quality management quite interesting.

  • Comment on Re: Re: Lots of subs in large program vs lots of small programs