in reply to Re: How's My Style Now?
in thread How's My Style Now?

Thanks for the suggestion. I see your point about making a sub-routine. I go back and forth on the idea of sub-routines: sometimes I can't get enough of them (e.g., that &panel_end() is just a print end_div() line). Other times, especially when I return to a program many months later and confuse myself with overuse of sub-routines, I decide to be more conservative. For instance, for CGI scripts I try to use only sub-routines (calling them from a library) to get data or to process it. I leave the printing of data in the program, not the library. I guess I could do a compromise and use sub-routines for printing, but leave them in the program, at the bottom. I just find that a program with only a list bunch of home-made functions can become confusing later when I need to modify the program.

-Spenser

That's Spenser, with an "s" like the detective.

Replies are listed 'Best First'.
Re^3: How's My Style Now?
by TGI (Parson) on Feb 08, 2010 at 19:22 UTC

    I understand the tension between too-much modularity and not enough. It's a continuing part of self-aware coding.

    Moving more of your code into modules with POD documentation will help make subroutines less burdensome.

    Using modules lets you group your code into specific name spaces, and when you use explicit imports, you have an instant reminder where the sub came from.

    Using POD lets you use perldoc to read about your code.

    Consider this code:

    use MyMod qw( foo ); foo( $somearg, $another, 57, 'bunnies' );

    I know that foo() comes from MyMod, so I can simply do a perldoc MyMod, to read about foo().

    This beats the heck out of:

    require './mylib.pl'; foo( $somearg, $another, 57, 'bunnies' ); # mylib.pl
    Escpecially since if I refactor MyMod or mylib, and move foo() to another file, failure to update the location info in my code causes a fatal error for the module. With library requires, I can easily get stuck with comments that lie.


    TGI says moo