If you need to work with 5.003, then avoid. Otherwise I would recommend this style in general.

Although doing it in a while loop is not normal for me. Usually I do things like:

foreach my $thing (@list) {
    #Something interesting
}
[download]

"Perl gurus recommend making variables available with the smallest possible declared scope"

Why is that? Is it for efficiency reasons or mainly for organization and readability purposes?

I tend to predeclare all my variables at the top of the file so they are listed in one place. I find it much easier to keep track of my variables that way. I guess I got into that habbit during my Pascal and C days.

--Glenn

As davorg said, because it is a good software engineering practice.

Pick up a good book on programming (eg Code Complete) and read up on the concepts of loose coupling vs tight coupling. Tightly scoped variables go hand in hand with loose coupling between different sections of code which goes hand in hand with code that is easier to maintain, adapt, and modify.

These principles have been known for decades, but far too many people don't know about them. Also a lot of people have (sorry to pick on you) misconceptions such as beliefs that you need to make it easy to keep track of all variables you use anywhere.

That is actually the opposite of what you should want.

You want to make it absolutely useless to keep track of as many variables as possible by giving them private scopes where they cannot accidentally have anything non-obvious happen to them. Guaranteeing no accidents with a tight scope is safer and easier to maintain than manually remembering which variables got used somewhere and so should not be accidentally stomped on.

However when you are done there are a small list of variables that you will need to give larger scopes to. (For instance package globals that you are willing to export.) It is still a good style to put those at the top. But now you get a second win. By winnowing down the list of global variables to the minimum necessary, you have made the list of important things to remember much smaller. Therefore you have just made it easier to keep track of things that you needed to track!

So the recommended style then works out to at the top of your file use strict to catch mistakes, use vars to declare in an obvious place everything that you need to track in your code, and then protect every little variable you need to use by making them lexicals with tiny scopes. The protection from scoping then protects those far more securely than you could do manually, and you will find it easier to track and manually protect the few that are left over.

Given the choice when hiring a Perl programmer, I would prefer to hire someone who understood good software engineering principles but didn't know Perl than I would to hire someone who knew a lot of Perl but thought good software engineering was bunk. I am confident that I can teach the first person to program in Perl. I don't know how to keep the second from being a hazard to the company's code-base.

"Why is that? Is it for efficiency reasons or mainly for organization and readability purposes?

Largely because it makes it less likely that you'll stomp all over another variable with the same name.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

# within
while (my $x = $count) {
    $count++;
    last if $count >= 5000000;
}

# without
my $x;
while ($x = $count) {
    $count++;
    last if $count >= 5000000;
}

Benchmark: timing 10 iterations of within, without...
    within: 40 wallclock secs (39.78 usr +  0.04 sys = 39.82 CPU) @  0
+.25/s (n=10)
   without: 35 wallclock secs (35.09 usr +  0.00 sys = 35.09 CPU) @  0
+.28/s (n=10)
[download]

There is some run-time action upon entering and exiting its scope, so there is indeed some overhead. It does not need to allocate and deallocate space, but Perl does need to manipulate reference counts and check that the old space allocated is for a variable not in use and so can be reassigned. (Just in case you saved a reference and kept a closure!) But even within this minimal loop the overhead is minor.

So yes, there is a small amount of overhead associated with the safer mechanism. However when you try conciously switching styles between projects you will quickly find that the safer style results in big wins in terms of reliability, development, and debugging. Besides which, aggressively modularizing your code etc gives you opportunities to later find and fix large algorithm mistakes. (Leading to better performance wins than optimizing the heck out of your code up front can do.)

The tiny performance difference is a really, really bad excuse for keeping a bad habit. For more on this topic, there is a sample section from Code Complete online.

I agree completely, and have been reluctant to move away from the while (my $var ...) style for that reason (except in cases where I'm expecting to iterate very tightly many thousands of times). A 15% win isn't much when we're talking about, like, picoseconds here. Heh.

It's not re-allocating memory each time through the loop. You can test that by doing this:

    my $count = 1;
    while (my $x = $count) {
        print \$x, "\n";
        last if ++$count > 5;
    }
[download]

If you run that, you should get something like:

    SCALAR(0x80e4aa8)
    SCALAR(0x80e4aa8)
    SCALAR(0x80e4aa8)
    SCALAR(0x80e4aa8)
    SCALAR(0x80e4aa8)
[download]

Each time through the loop $x is at the same memory location. So it's not re-allocating memory.

As tilly mentions in his post, Perl does have to do *some* extra things--but re-allocating memory isn't one of them. :)

If it were tightly de-allocating and re-allocating, is it not unreasonable to expect that they might end up at the same address? Not that I disagree with you; I'm hardly the expert. I rather think that what you say is actually the case.

But yah, I think tilly's hit it on the head.

You are correct Fastolfe, the re-allocation happens in the loop. However, this is the behavior that is GOOD. The cost of the allocation is a great deal less than this

my $x='ok';
# scads of code
my $x=300;
while ($x--) {
  do_something_with($x);
  }
# scads of code...
print "$final" if ($x eq 'ok'); #kaboom
[download]

In the end, when you do a "-w" and it complains that '$x won't stay shared' or something at the second my, your lesser perl wizard is likely to take the "my" off since the variable is already declared. Ouch.

In the end, you suffer the cost of extra work on the backside to protect yourself from the future.

--
$you = new YOU;
honk() if $you->love(perl)

I think you slightly mis-stated the common construct, it should be:

while( my $var= func( @args))
  { # do something
  }
[download]

Otherwise the my $var returns undef which might not be what you want (the loop would not be executed).

As far as I know this is perfectly kosher. $var is declared, its scope is the inner block and I would bet (Perl guts Gurus can confirm this) that the whole thing is optimized so the variable is actually built (ie allocated) only once.

I'd be interested in knowing what are your local guru arguments.

I did the same on occasion, until corrected here at PM.
    cheers,
    Don
    striving for Perl Adept

while (my $var = <FILE>) {}  # or similar
[download]

-- tune

Tell him it is NOT redeclaring, it is only allocated
once, at the 2..nth time in the while the 1st declared
variable is used...

It is just a local, like this:


...
{
 my $var=<FILE>;
 while ($Var)
 {
  ...
  ...
  $var=<FILE>;
 };
}
# $Var out of scope
...
[download]


Try that on him ;))

GrtZ!,

ChOas