On scoping temporaries or global settings

I've found that limiting the scope of my temporaries has reduced my debugging time. So when I need a "scratch variable" for a few steps, or need to set something dangerously global like $/ for a few steps, I pop open a block and do the work there.

Doing so makes it very clear to the reader that this variable doesn't need a long lifetime, and even ensures that the action won't collide with a larger-scoped variable. It's a slick trick, and works nicely.

I've also recently started using the idiom of a one-iteration foreach loop to "name" a value rather than setting up a temporary, like:

for ($some->complicated(@value)->{$to_fetch}) {
  print; # print it
  print LOGFILE $_; # and to the logfile
  substr($_, 0, 1, ""); # remove its first character
}
[download]

It's a nice idiom, and is also the explanation of why Larry intentially allows foreach to be spelled "f-o-r". And the "backwards foreach" makes it even easier:

do_this($_), do_that($_, @moreargs) for $some{$complicated}{$value};
[download]

-- Randal L. Schwartz, Perl hacker

Comment on On scoping temporaries or global settings Select or Download Code

Replies are listed 'Best First'.
For - Loop construct 'cheaper' than local variable? by C-Keen (Monk) on Sep 29, 2001 at 23:28 UTC
Doesn't the for-loop construct use more internal resources than a local variable? As comming from the C programming section a waste of resources looks somehow awkwardly to me. But it sure is more readable this way. Regards, C-Keen	[reply]
Re: For - Loop construct 'cheaper' than local variable? by Brovnik (Hermit) on Sep 30, 2001 at 02:44 UTC
You really shouldn't be worryomg about use of reseources at this level. Focus on good style, readability, ease of coding, major performance issues, and all that other good stuff. A decent compiler should optimise this sort of construct down to almost nothing (at most a single extra test), which will not be noticeable in the overall performance unless it is in the inside of a very tight loop. Perl already does some interesting tricks, such as removing if statements from the code and replacing it with and/or, so trying to second guess what the byte code looks like is a waste of time. The gain you will get in readability and hence reuse, ability to maintain should outweigh any effect in the code. -- Brovnik	[reply]