Re: macro like "my" in Perl

[Alex Shinn]

>>>>> "Lynn" == Lynn Winebarger <address@hidden> writes:

    Lynn> On Tuesday 25 June 2002 21:25, Alex Shinn wrote:
    >> I guess that's the real complaint... nested lets indent the code
    >> too much, but for some straight but very long procedural
    >> algorithms it's less clear to make all the variable decls up
    >> front when their use is localized.
        
    Lynn> If it's very procedural, why is it indented so far that nested
    Lynn> lets will indent the code "too much"?

Procedural code doesn't imply you don't need new variables... in fact in
procedural code you tend to use variables and state much more than
functional code.  The notion that lots of indentation shows good code is
vastly over-simplified.

I don't know what the OP's use for this was, but I have seen code where
Perl style variable declarations right before their use is more
readable.  Consider a quick and dirty CGI script, which in Perl may
follow a form like:

  my $foo = computeFoo();
  print funcOfFoo1($foo);
  ...
  print funcOfFooN($foo);

  my $bar = computeBar($foo);
  print funcOfBar1($bar);
  ...
  print funcOfBarN($bar);

This is, of course, a matter of style, but I find in these cases it
helps to define bar and initialize it right before the section it's used
in, rather than at the top where foo is initialized.  Each block is thus
isolated and easier to read.  Some people will say this is ugly,
unfactored code, and it would be better to pull out all the funcOfFoo's
together and funcOfBar's into an enclosing function, but that's just
blindly following principles without understanding them.  Why break up
code that only gets used in one place?  It just causes more to read and
more moving back and forth between source code.

And I'm not alone in this, a lot of Perl gets written in this style.
Then again, a lot of Perl is used for things like quick and dirty CGI
scripts :)

    Lynn> And how is not indenting new scopes going to clarify where
    Lynn> "localized" definitions come from?  (Where "localized" is
    Lynn> visual only, as the declaration extends to the end of the
    Lynn> enclosing block).

Extra lines between each block, as above, helps.  Also using the more
readable define-my or some such that will stand out with syntax
highlighting would be good.

-- 
Alex