Re: To sub or not to sub, that is the question?

From "The Pragmatic Programmer" (tip #22):

DRY - Don't Repeat Yourself - Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

In short, when in doubt, make a sub. Name the sub properly, and you have replace several lines of code in the original location with a sub call that is, in effect, a comment.

As to sub size, someone suggested no more than one page. I follow the rule that a sub (including comments and white-space) must fit on my screen without scrolling. Only excpeption is if there is a long list of constants or other literal text.

I find it much easier to have subs like:

sub foo {
    readstuff();
    formatstuff();
    writestuff() if check_stuff();
}
[download]

I have seen some code that reads like English until you get to the subs that actually do anything. And the subs that do anything are just a few lines long, easy to understand, and documented by the sub name (check_and_exit_if_bad()).

Comment on Re: To sub or not to sub, that is the question? Download Code

Replies are listed 'Best First'.
Re: Re: To sub or not to sub, that is the question? by ellem (Hermit) on Jun 26, 2001 at 20:58 UTC
I have read the Pragmatic Programmer and it depressed me since I realized that: IF the book was correct THEN I am the worst Programmer in the world ELSIF the book was mostly correct THEN I am part of the really bad programmers My uncle who is a great programmer but no friend of Perl suggested that Perl wasn't terribly compatible with that book b/c it is not an Orthogonal language (and a lot of other things I won't wite here.) What do you think of that? -- lmoran@wtsgSPAM.com print "\x{263a}"	[reply]
Re: Re: To sub or not to sub, that is the question? by voyager (Friar) on Jun 26, 2001 at 22:30 UTC
As the parent of 11 & 13 year-old boys, the role the book plays with me (or the me from a few years ago), is the same as I play with my sons. I was always annoyed at my parents for telling to wear a jacket (rain coat, hat, etc) just in case. When it got cold, and I shivered, I never credited my parents with foresight. Now, I find myself contantly reminding my kids to bring a jacket "just in case". A lot of the things in the book are ways that are differrent than you might choose (or stumble into), but don't always take longer. If you get in the habit of doing things "the right way", you won't be any slower, and if the unexpected happens, you'll be far ahead. In the example of "when to sub", the second use of the code it's faster to cut-n-paste then make a seperate sub and call from two places. But as soon as you need to make a change, or you have a third use for the code, you're already in the hole. I had a colleague once who defended his lack of subs because when you make a new sub you have to name it, and he suffered from "writer's block". Oh well.	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks