Cheers,

JohnGG

Declare them in as small a scope as you can so there is less chance that they will be misused and their intended use is more evident. Especially this is true if you initialise the variable where it is declared.

The "use the tightest scoping possible" rule is very common these days (and therefore, probably what you should do), though just for the sake of argument...

If you use subroutine scope (always declare your variables near the beginning of your subs), you can make the main body of the code a little cleaner by eliminating the embedded "my"s scattered around. You should still have the benefit of reasonably tight lexical scoping... provided that your subroutines are short and to the point. If you need tighter scoping for some reason, maybe what you really need is more and shorter subs, eh?

I suspect that the main reason that most of us use "tight scoping" has to do with simple laziness: when we want to create a variable, we don't feel like skipping back up to a declaration section to do it. But if it improves readability a little, isn't it worth doing?

I also might make the point that perl's rules about where you're allowed to insert a "my" are a little hard to grasp.
At this point, you probably know that this works:

for my $item (@items) { ... }
[download]

chomp(
  my @lines = <$fh>
);
[download]

Improves readability by using "subroutine" scope? Far, far, FAR from it. Tightest scope possible improves readability because I don't have to go back to find out what else has played with this variable. It also means that when I figure out I don't need a variable any longer, I'm more likely to remove it - I've seen functions start with "my (<20 variables here>)" - and I notice one that looks out of place, and then can't find it being used anymore. I don't see nearly as many unused variables being declared when following tightest-scope-possible rules.

There is a reason why C++ started to allow declarations of local variables anywhere in a block, and not just at the top as its predecessor, C, did. Because it's more readable. And maintainable. (Well, that, and delayed construction of variables on the stack only made sense - forcing them all to the top of the block would be impossible.) And now, C allows it, too.

Mandatory declare-at-the-top semantics is going the way of the dodo. And for good reason. It was only ever there due to limitations of the compilers (allowing declarations anywhere is hard - especially in compiled languages with a stack). Now that even the compilers are being written in higher-level languages, with better automatic memory management, there's much less excuse in granting this type of flexibility for readability.

As for your question - yes, I know that works. And just to convince myself that I was right, I wrote a quick program to prove it ;-) Perl is more generous with where you can put "my" than you may think. You probably didn't know you could use it for the lexical filehandle in the first place:

#!/usr/bin/perl

use strict;
use warnings;

open my $fh, '<', $0;
chomp(my @lines = <$fh>);

print "[$_]\n" for @lines;
[download]

No lines starting with "my" - but, I do end up with both a lexical scalar (filehandle) and a lexical array.

If consistency within an application is important, so, too is consistency of convention within a language. Therefore, there should be a single convention in use within Perl, for much the same reasons. The problem is that people can't agree on which convention to use, and there's always one more way to do it...

Absolutely wrong for a language known for TIMTOWTDI

-Lee
"To be civilized is to deny one's nature."