>> 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.
> 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: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
