Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Style question regarding subroutines and lexical variables

Reply
Thread Tools

Style question regarding subroutines and lexical variables

 
 
Joseph Ellis
Guest
Posts: n/a
 
      07-24-2003
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
 
Reply With Quote
 
 
 
 
Joseph Ellis
Guest
Posts: n/a
 
      07-24-2003
On 24 Jul 2003 03:33:32 GMT, "A. Sinan Unur" <(E-Mail Removed)>
wrote:

>Joseph Ellis <(E-Mail Removed)> wrote in
>news:(E-Mail Removed) :
>
>> 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.

>
>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
>
>> 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;
>> }

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

>
>>
>> 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?

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

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

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

 
Reply With Quote
 
 
 
 
Joseph Ellis
Guest
Posts: n/a
 
      07-24-2003
On Thu, 24 Jul 2003 08:51:28 -0500, http://www.velocityreviews.com/forums/(E-Mail Removed) (Tad
McClellan) wrote:

>Joseph Ellis <(E-Mail Removed)> wrote:
>> On 24 Jul 2003 03:33:32 GMT, "A. Sinan Unur" <(E-Mail Removed)>
>> wrote:
>>>Joseph Ellis <(E-Mail Removed)> wrote in
>>>news:(E-Mail Removed) :

>
>
>>>> my $l, $m, $n, $o, $p;

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


Yes. These were just quickly-typed examples.

>
>
>>>> &two();

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

> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>aka: cheating
>
>
>>> 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".

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

 
Reply With Quote
 
Malte Ubl
Guest
Posts: n/a
 
      07-24-2003
A. Sinan Unur wrote:
> 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

 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      07-24-2003
Joseph Ellis <(E-Mail Removed)> wrote:
> On Thu, 24 Jul 2003 08:51:28 -0500, (E-Mail Removed) (Tad
> McClellan) wrote:



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



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)




--
Tad McClellan SGML consulting
(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Joseph Ellis
Guest
Posts: n/a
 
      07-24-2003
On Thu, 24 Jul 2003 11:00:42 -0500, (E-Mail Removed) (Tad
McClellan) wrote:

>Joseph Ellis <(E-Mail Removed)> wrote:
>> On Thu, 24 Jul 2003 08:51:28 -0500, (E-Mail Removed) (Tad
>> McClellan) wrote:

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

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


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
 
Reply With Quote
 
Joseph Ellis
Guest
Posts: n/a
 
      07-24-2003
On Thu, 24 Jul 2003 16:18:46 +0200, Malte Ubl <(E-Mail Removed)>
wrote:

>A. Sinan Unur wrote:
>> 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


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Style and subroutines in Perl Programs pgodfrin Perl Misc 8 03-13-2008 08:47 PM
variables not being passed into subroutines echohtp@gmail.com Perl Misc 5 07-12-2005 08:56 PM
convention regarding lexical filehandles Paul Lalli Perl Misc 14 01-16-2005 04:07 PM
Lexical variables - speed penalty? Joakim Hove C Programming 3 10-07-2004 10:44 PM
Strange behaviour regarding lexical scopes? Michal Ruby 1 08-27-2004 10:39 AM



Advertisments