Style question regarding subroutines and lexical variables

[Joseph Ellis]

Hello all...I am fairly new to Perl and am hoping to glean some advice
from those of you who have been around the Perl block a few times.

I am currently writing a program that consists of a handful of
subroutines, with one subroutine calling another subroutine, etc, all
to generate a particular hash.

So far I'm giving most of my variables file scope, but I don't think
that's really the best thing to do, stylistically and otherwise.

Consider the following (syntax notwithstanding)...

my $l, $m, $n, $o, $p;
my %hash;

sub one {
use / modify all those global variables;
&two();
return %hash;
}

sub two {
use / modify a couple of the scalars and the hash;
&three();
}

sub three {
use / modify a couple of the other scalars and the hash
}

Would it be advisable / more efficient / more aesthetically pleasing /
just plain better to create lexical variables within each subroutine,
passing copies of them around as arguments, or is the above
pseudo-script fine the way it is?

What if there were 15 variables and 20 subroutines? Or 30 variables
and 5 subroutines?

I'm just curious as to which method is better (subjectively or
objectively).

Thanks.

Joseph

 

[Joseph Ellis]

Disclaimer: I haven't been around the block even once yet.

If you haven't done so already, I will recommend taking a look at:

perldoc perlsub


perlsub has this to say:

Not only does the "&" form make the argument list optional, it also
disables any prototype checking on arguments you do provide. This is
partly for historical reasons, and partly for having a convenient way
to cheat if you know what you're doing. See Prototypes below.

You really do not need to use &two(), two() will do just fine.

I have read that, but so far I am sticking with using the &, because I
don't think I sufficiently know what I'm doing yet to "cheat".

You can pass around references to the hashes. That way, you do not need
to make changes to the code in the subroutines if you change the names of
the hashes or other variables you are modifying, and you avoid creating
copies of large data structures.

Ahh, that sounds like what I'm looking for. I haven't learned
anything about references yet. The only book I have is the Llama,
which suggests perlref and perlreftut. I'll study more there.

Regardless of language, if I see a method/function/subroutine being
called with 30 arguments, I am inclined to think there is a design issue.
But I am really not sure what you mean by these.

I was just being hypothetical, which is significantly different than
hypothetically being...

Thanks for your help.

Sinan

Joseph

 

[Joseph Ellis]

I hope your real code makes better choices regarding names...

Yes. These were just quickly-typed examples.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

aka: cheating




Errr, you have it backwards.

Using the ampersand is what allows cheating, so if you want to
eliminate the possibility of cheating, then eliminate the use
of ampersand on function calls.

Ahh...I see. I was right though; I really don't know what I'm doing.
I don't understand what prototypes and prototype checking are all
about. I'll have to look that up.

Thanks for the clarification.

Joseph

 

[Malte Ubl]

Regardless of language, if I see a method/function/subroutine being
called with 30 arguments, I am inclined to think there is a design issue.

Just to make it clear. The design issue is not solved by using global
variables, which are only needed is a few corner cases of programming.

malte

 

[Tad McClellan]

Ahh...I see. I was right though; I really don't know what I'm doing.

If you are just starting with Perl, then your plate is already
pretty full with things to look into.

You should apply the Pareto Principle in your effort to learn Perl.

Knowing 20% of Perl can get 80% of commmon programming tasks done.

Concentrate on the most-important 20% first, move on to the others
much later when you have time (and you'll have more time because
the 20% you've learned is getting lots of your everyday work done).

I don't understand what prototypes and prototype checking are all
about.

You probably don't need to (yet). Perl's prototypes are in the 80%.

The 20%-part of prototypes is simply:

Do not circumvent them if they are present.

And you already know how to avoid circumventing them.

Prototypes have to to with argument checking, if they are present
then you must call the functions with correct argument types.

I'll have to look that up.

Save the time for something with a larger payback, like reading any
of these end-to-end:

perldoc perlrun
perldoc perldata
perldoc perlsyn
perldoc perlop
perldoc perlsub

and maybe:

perldoc perlintro
perldoc perlrequick
perldoc perlretut
perldoc perlreftut
perldoc perlvar

and know to look things up as needed in:

perldoc perldiag
perldoc -f (perlfunc)
perldoc -q (perlfaq1 - perlfaq9)

 

[Joseph Ellis]

If you are just starting with Perl, then your plate is already
pretty full with things to look into.

Yeah no kidding...

You should apply the Pareto Principle in your effort to learn Perl.

Knowing 20% of Perl can get 80% of commmon programming tasks done.

Concentrate on the most-important 20% first, move on to the others
much later when you have time (and you'll have more time because
the 20% you've learned is getting lots of your everyday work done).




You probably don't need to (yet). Perl's prototypes are in the 80%.

The 20%-part of prototypes is simply:

Do not circumvent them if they are present.

And you already know how to avoid circumventing them.

Prototypes have to to with argument checking, if they are present
then you must call the functions with correct argument types.




Save the time for something with a larger payback, like reading any
of these end-to-end:

perldoc perlrun
perldoc perldata
perldoc perlsyn
perldoc perlop
perldoc perlsub

and maybe:

perldoc perlintro
perldoc perlrequick
perldoc perlretut
perldoc perlreftut
perldoc perlvar

and know to look things up as needed in:

perldoc perldiag
perldoc -f (perlfunc)
perldoc -q (perlfaq1 - perlfaq9)

Thanks for the direction...at this stage in learning Perl, deciding
what aspects to devote a lot of attention to vs. what to reserve for
later learning can be difficult.

I'd say I'm using 10% of Perl to get 60% of my programming done. The
other 40% is painfully assembled piecemeal from a hodge-podge of
suggestions and tidbits of information gleaned from cursory readings
of online documentation and the like. I've been treating perldoc more
like an index of topics rather than something to be read end-to-end.
I guess I'll now focus on the latter, as you've suggested.

Have nice days.

Joseph

 

[Joseph Ellis]

Just to make it clear. The design issue is not solved by using global
variables, which are only needed is a few corner cases of programming.

malte

Of course.

I am sure that adhering to one extreme (having all global variables)
or another (passing around 30 arguments) is not a sound or efficient
way to program. I'm just still trying to learn where the best place
to be in that continuum is.

Thanks for the input everyone...you've all helped a great deal.

Joseph