If you have long functions and long blocks, lots of other things go askew. Refactoring aggressively into shorter functions/methods/subroutines/whatever so that you can see the entire scope at once, just-in-time declarations are unremarkable. If you can't take the entire scope in at a glance, you do have to work harder to keep track of the matter.
Why do I like just-in-time declaration?
Consider
Under most circumstances, $foo is meaningless outside the loop, so it makes sense to limit its scope to just the loop. Similarly, a variable used only within a block is best declared within that block so that it doesn't leak (for whatever useful sense of "leak" applies).foreach my $foo (stuff) { do stuff with $foo }
The real appeal is an application of the concept of "least privilege" (usually invoked in the context of security) to how large the scope of a variable needs to be. Less is more.
I was taking a stick to some code I inherited. The programmer was learning Perl on the fly and wrote a lot of C code in perl, without using strict or warnings. He did use "my" as he went along. I made it strict and warnings clean, but it was quaint, especially dealing with 1300 line routines. I applied "my" liberally. From time to time, I would get the complaint that a given variable was already lexical, but it did eventually yield the field to me...
I try to write short routines with variables' scopes as limited as I can make them.
In reply to Re^3: coding rules
by herveus
in thread coding rules
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |