Re: Program structure: subs vs modules vs Selfloader

Looks to me like there isn't much reason to have the subs larger or small in the first place.

IMO there are generally two reasons to have a subroutine.

The code will be executed multiple times in the script.
You want to modularize the code for re-use

Adding subroutines where there's no clear reason for one just adds confusion to a script.

That being said, if you do break things up into subroutines, it's generally good form to ensure that each subroutine does one thing and one thing only. Short and too the point.

A run-on subroutine suffers from the same disease as a run-on sentence.

I recommend reading Code Complete by Steve McConnell (M$ press). It a very good book on coding style and best practices.

Cheers

Comment on Re: Program structure: subs vs modules vs Selfloader

Replies are listed 'Best First'.
Program structure: appeasing the Gods by awwaiid (Friar) on Jun 23, 2004 at 01:49 UTC
There are many more reasons to separate code into subroutines (and modules) than what you have listed. In fact, it sounds like both of your points are actually the same thing -- the chunk of code in question is going to be called multiple times or somehow used in multiple ways (by "re-use" I'm guessing you mean in other projects... so perhaps describing that as being used in multiple ways is a stretch... but bear with me here). I believe that this might be the reason subs were invented in the first place, but very soon afterward the ancients became aware of yet another purpose for subs. Thus were discovered the offering of Organization and Structure to the Gods. A good program reads like a good book. A good book has a nicely structured table of contents, footnotes and references to other works, and references to other sections in the book itself (and a good index!). There is a certain balance to be struck when dealing with references, however. Too many and it will be a dry read with a footnote after every third word. Too few and some connections will be lost upon the reader. Sometimes, however, it is not appropriate to refer to other pieces of the book. It may not be appropriate to call some organizational subroutines in your code more than once. The table of contents is still very important, however, and breaking your big sub into many smaller subs (or even modules) will not only appease the gods, but it will also make your program a better read. Your big sub should become the table of contents, and reading the little subs you create from it is the text itself. I would say that a run-on subroutine suffers from the same disease as a book with no table-of-contents... something which no number of comments in the code can fix (unless of course the comments themselves break things into sections and lay them out like a table of contents... but as an ancient once said, "Do not say something in a comment which you can say clearly in code.")	[reply]

Replies are listed 'Best First'.

Program structure: appeasing the Gods
by awwaiid (Friar) on Jun 23, 2004 at 01:49 UTC

A good program reads like a good book. A good book has a nicely structured table of contents, footnotes and references to other works, and references to other sections in the book itself (and a good index!). There is a certain balance to be struck when dealing with references, however. Too many and it will be a dry read with a footnote after every third word. Too few and some connections will be lost upon the reader.

Sometimes, however, it is not appropriate to refer to other pieces of the book. It may not be appropriate to call some organizational subroutines in your code more than once. The table of contents is still very important, however, and breaking your big sub into many smaller subs (or even modules) will not only appease the gods, but it will also make your program a better read. Your big sub should become the table of contents, and reading the little subs you create from it is the text itself.

I would say that a run-on subroutine suffers from the same disease as a book with no table-of-contents... something which no number of comments in the code can fix (unless of course the comments themselves break things into sections and lay them out like a table of contents... but as an ancient once said, "Do not say something in a comment which you can say clearly in code.")

[reply]