Re: Style: buried variables or double referencing?

Greetings punch_card_don,

Each of your suggested styles has merit depending on the particulars of the situation. Context is everything. There's nothing in your code examples that would make me shiver if I had to maintain it. (Although, "...many lines of code later..." does cause some pause, I have to admit.) A couple key things to consider:

Use very clear nouns for variable names that are short and accurately describe the data
Keep relevant code together; don't pre-define variables too early; in other words, don't my a scalar on line 4 then use it for the first time on line 100

I tend to write really compact code, but I understand that it can be more difficult for someone else to maintain. Here's what I'd be tempted to do:

for (0 .. (($some_variable eq 'x') ? 14 : 9 )) {
    print $_, "\n"; # or whatever goes on in here...
}
[download]

TMTOWTDI, and you've already posted a few good ways.

gryphon
Whitepages.com Development Manager (DSMS)
code('Perl') || die;

Comment on Re: Style: buried variables or double referencing? Download Code

Replies are listed 'Best First'.
Re^2: Style: buried variables or double referencing? by punch_card_don (Curate) on Aug 20, 2005 at 16:21 UTC
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.	[reply]
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/	[reply] [d/l]
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.	[reply]