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

I am sure that many of the Perl Wizards on this site will condemn my methods, and indeed you yourself will likely turn your nose up and laugh at what are (I admit it) unconventional and "sloppy" programming techniques. I have only been in the Perl business for 18months so you probably all have years of exp on me. Still I'm gonna tell you what I do because most of important of all it works for me

I'm in the business of writing perl programs of roughly 500-4000 lines long. They are not beginners stuff, but still they aren't incredibly perl-ish as I tend to err on the side of making them readible by others in the dept that may be fresh to Perl

My strategy is to have one main script that contains the fundamental login of sequential operation, and then I have a load of other files with tasty sub-procedures in them that I use like libraries.

Take for example my current project, a pdf metaeditor. I have one main script "editpdfmetadata.pl" and then another script "pdf-utils.pl" that contains frequently used pdf operations; getTitle, setTitle, getAuthor etc... Again in DB applications I often separate out DB operations into a different script (or two) just so I know where everything lives. I never allow my scripts to grow beyond 300/400 lines of code.

The main failing in my scripts that people will undoubtably hate me for is using loads of require statements. I usually have a heafty bundle of them at the top of my main script to import all the sub procedres that I need to use.

It's not the most elegant way to program Perl but it works for me. Comments about using require statements like this would be appreciated as its nice to get others views.

-M

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

Replies are listed 'Best First'.
Re: Re: Lots of subs in large program vs lots of small programs
by tilly (Archbishop) on Oct 31, 2003 at 20:38 UTC
    And how is someone reading the script to know what function is defined where? See my reply to Simpler alternative to modules for my thoughts on what is wrong with just using a ton of requires, how to do it better, and why the alternative is better.
      And how is someone reading the script to know what function is defined where? Pod.
        And how is someone reading the script to know what function is defined where?
        Pod.
        Red flag. You are asking for synchronization of documentation and code, and then further asking for everyone to always keep in mind all of the relevant documentation whenever they produce more code.

        If this was an effective solution, then good programmers wouldn't mind lots of global variables and lots of tightly coupled functions. After all, if you can keep track of everything, you can always come up with shorter answers that way.

        For more thoughts on why verbose documentation is not a good resolution to programming problems, see the discussion starting at Re (tilly) 2 (disagree): Another commenting question,.

Re: Re: Lots of subs in large program vs lots of small programs
by runrig (Abbot) on Oct 31, 2003 at 22:29 UTC
    Unless it is obvious by reading the program from which required file each function comes (e.g. have "require 'quality.pl'" only import functions that are named 'quality_*', which would still be a fairly bad way to do it), then I'd use the Exporter module and use the modules (first turning them into proper modules with a package statement) with an import list so that the program is self-documented as to where functions originate from.
Re: Re: Lots of subs in large program vs lots of small programs
by Art_XIV (Hermit) on Oct 31, 2003 at 21:15 UTC

    I doubt that any would condemn your practices, but you might get some smirks because you seem to be just an itty-bitty-bit off from doing something quite orthodox w/o realizing it.

    If you place your tasty subroutines into a module and use 'use' instead of 'require' then BINGO! You're following a very standard Perl practice. :)

Re: Re: Lots of subs in large program vs lots of small programs
by bradcathey (Prior) on Oct 31, 2003 at 21:16 UTC
    Also, the Camel book (blue edition, p.128) recommends use instead of require because use acts as a BEGIN block, and in essence, globally declares the modules at compile time (or something to that affect).