Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: Style: buried variables or double referencing?

by punch_card_don (Curate)
on Aug 20, 2005 at 16:21 UTC ( [id://485398]=note: print w/replies, xml ) Need Help??


in reply to Re: Style: buried variables or double referencing?
in thread Style: buried variables or double referencing?

Although, "...many lines of code later..." does cause some pause, I have to admit.

"many lines of code" = about 1,500

and that's another style question. It's that big because it performs four phases of a multi-phase user inquiry to a database. That is, offer some options in a form, receive user selections, search database for more options that follow loically from the user's selections, and repeat total of four times. All phases use a large collection of identical constants, many identical sub-routines, but do a lot of crunching that's unique to that phase. So Having all four phases in one script with a phase-sorter at the beginning means:

  • reduced total code lines because common elements are not rerpoduced in separate scripts
  • during development, a change to any common element only has to be made once instad of four times.
At the same time, I've sometimes wondered - is this considered a large script? Unweildy? Does it impact peformance to have to load one large script?

Forget that fear of gravity,
Get a little savagery in your life.

Replies are listed 'Best First'.
Re^3: Style: buried variables or double referencing?
by holli (Abbot) on Aug 20, 2005 at 18:39 UTC
    "many lines of code" = about 1,500
    How do you create your html? If it is generated with print and heredocs within the script, you probably can reduce its size by using a templating mechanism and moving the html to separate files.

    Also, if you have such a big number of constants in your script, I would put them in some kind of configuration file, so you can change them without having to edit the script.
    • reduced total code lines because common elements are not rerpoduced in separate scripts
    • during development, a change to any common element only has to be made once instad of four times.
    There is another way to achieve this. Put your common code into modules.


    holli, /regexed monk/
Re^3: Style: buried variables or double referencing?
by merlyn (Sage) on Aug 21, 2005 at 15:09 UTC
    So Having all four phases in one script
    All in one script? How do you test that? I would have broken it into modules the moment I hit 500 lines. Especially since there is common code, and a large amount of it, that receives varying parameters: perfect thing to want to test that formally so that I can isolate a problem between called subroutines and calling code.
    reduced total code lines because common elements are not rerpoduced in separate scripts
    Uh, that's what a module is for. If you have cut-n-paste worry, then you aren't using modules right
    a change to any common element only has to be made once instad of four times
    Again, a sign that you don't understand modular development.

    I'm betting I would cringe looking at your "script". Mostly because I've seen far too many already in my life, and I think I've nearly used up my quota. {grin}

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://485398]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-03-28 22:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found