> -----Original Message-----
> From: Bryan R Harris [mailto:[email protected]]
> Sent: Friday, December 11, 2009 15:10
> To: Beginners Perl
> Subject: Re: being smart about script structure
>
>
>
>
> >> Seems like a waste to do step 2 in a subroutine since we
> only do it once,
> >> but it does fill the main body of the script with
> code-noise that makes it
> >> harder to debug overall logic problems... Not much logic here, but
> >> certainly in more complex scripts.
> >
> > A waste of what exactly? You don't have a limited budget of
> "sub" keywords.
>
> I guess I figured you had to build in structure (variables?)
> to be able to
> pass things back and forth from subroutines that normally you
> wouldn't have
> to set up.
>
> For example, if I'm populating a complex variable @d with
> lots of pointers,
> hashes, arrays, etc. within, if I populate that within a
> subroutine, how do
> I get it back out conveniently without it making a whole
> nother copy of it
> outside? If it's 500 MB, isn't that horribly inefficient?
> Plus, I have to
> keep track of it.
>
You pass as a refernce as ni
called_sub(\...@d);
Now when you update, you are updating @d and not a copy.
If you have any questions and/or problems, please let me know.
Thanks.
Wags ;)
David R. Wagner
Senior Programmer Analyst
FedEx Freight Systems
1.719.484.2097 Tel
1.719.484.2419 Fax
1.408.623.5963 Cell
http://fedex.com/us
>
>
> > Subroutines are not just about code reuse. Which is more readable:
> >
> > my $x = [
> > # Big complex data structure
> > # ...
> > # ...
> > # ...
> > # ...
> > ];
> >
> > my $y = [
> > # Big complex data structure
> > # ...
> > # ...
> > # ...
> > # ...
> > ];
> >
> > for my $p ($x) {
> > for my $q ($y) {
> > #Big
> > # complex
> > # multi-statement
> > # manipulation
> > # of
> > # $p
> > # and
> > # $q
> > }
> > }
> >
> > Or this:
> >
> > my $x = populate_x();
> > my $y = populate_y();
> > for my $p (@$x) {
> > for my $q (@$y) {
> > process_pq($p, $q);
> > }
> > }
> >
> > Or even:
> > my $x = populate_x();
> > my $y = populate_y();
> > process_xy($x, $y); # xy_process now contains the for loops
>
> I guess my only struggle there is that any perl person can
> read the perl
> code. At first glance, I have no clue what "populate_x()"
> does because you
> gave it a name that's not in the camel book.
>
>
>
> > The point is that in the first version, you are constantly bouncing
> > from the big-picture ideas to the low-level messy details. By
> > abstracting code out into subroutines populate_x(), populate_y() and
> > process_xy(), you have the main script which deals in big ideas, and
> > three subroutines which deal with messy details. A subroutine should
> > do one thing, and do it well.
>
> This is terrific advice.
>
>
> >> Any suggestions? Where can I read more on this stuff?
What questions
> >> should I be asking that I'm not smart enough to ask?
> >
> > The best that I can suggest is to read other people's code and ask
> > other people to read your code. Think of a specific example and come
> > up with a plan of how you would code it, and ask for criticism.
>
> No other perl programmers here, unfortunately. Good advice, though.
>
> - Bryan
>
>
>
>
> --
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> http://learn.perl.org/
>
>
>
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
http://learn.perl.org/
