in reply to Re^2: coding rules
in thread coding rules

Howdy!

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 

foreach my $foo (stuff)
{
    do stuff with $foo
}

[download]
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).

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.

yours,
Michael

Replies are listed 'Best First'.
Re^4: coding rules
by Anonymous Monk on Jun 10, 2005 at 20:56 UTC
    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.

    That's quite true. During my refactoring efforts, I found that when I knew how many variables were in a function, I knew roughly how complex the function would be. A function with 1,000 lines, but only 3 scalars values is usually simpler to understand than a 50 line function operating on a maze of 30 different interdependant data structures.

    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).

    Hmm... I guess I'm not sure in what context you'ld want to use a unnamed block for a section of meaningful code.

    If a section of code does something complex enough to wrap in an unnamed block, then, to me, that block needs documenting. Since all function get names, documentaiton about purpose, usage, side effects, and so forth, then, to me,it seems like the natural place to put such a code block. I'm not sure how I'm invent a nice documentation standard to apply to such unnamed code blocks; nor really, why I'd want one. Functions are essentially just blocks of code with names and special scoping rules. :-)

    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 guess I tend to apply the "less is more" philosophy to code correctness first, and variable scoping second. I've spent way too many wasted hours trying to fix a bugs that only existed because someone got tricky with scope, and shadowed something they didn't intend, or wrapped code in a conditional or a loop, and thereby unknowingly negated the entire point of the code they'ld so painstakingly written. If they hadn't tried to be so clever, I wouldn't have been cleaning up so many of their mistakes. Like you said, less is more. But maybe that's just the bitterness talking. ;-)

    I try to write short routines with variables' scopes as limited as I can make them.

    I try to write short routines with variables scoped at file level: that way I know there can't be any scoping or shadowing errors. If the code is short, then I'm not risking exposing too much: and if the code can be broken out into scoping blocks, I hide it behind a function call interface and keep it even more removed from the calling function. Are there any hidden drawbacks to this approach that I'm missing, though, save perhaps ideological ones? I'm less concerned with conceptual "least priviledge", and more with ensuring that variables are used correctly in practice. If the functions are always short, this should be easy in any case, right?

    Or am I still missing something signficant?

    Ytrew

[reply]

In Section Meditations