Style question regarding subroutines and lexical variables

Discussion in 'Perl Misc' started by Joseph Ellis, Jul 24, 2003.

  1. Joseph Ellis

    Joseph Ellis Guest

    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, Jul 24, 2003
    #1
    1. Advertising

  2. Joseph Ellis

    Joseph Ellis Guest

    On 24 Jul 2003 03:33:32 GMT, "A. Sinan Unur" <>
    wrote:

    >Joseph Ellis <> wrote in
    >news::
    >
    >> 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
     
    Joseph Ellis, Jul 24, 2003
    #2
    1. Advertising

  3. Joseph Ellis

    Joseph Ellis Guest

    On Thu, 24 Jul 2003 08:51:28 -0500, (Tad
    McClellan) wrote:

    >Joseph Ellis <> wrote:
    >> On 24 Jul 2003 03:33:32 GMT, "A. Sinan Unur" <>
    >> wrote:
    >>>Joseph Ellis <> wrote in
    >>>news::

    >
    >
    >>>> 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
     
    Joseph Ellis, Jul 24, 2003
    #3
  4. Joseph Ellis

    Malte Ubl Guest

    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
     
    Malte Ubl, Jul 24, 2003
    #4
  5. Joseph Ellis <> wrote:
    > On Thu, 24 Jul 2003 08:51:28 -0500, (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
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jul 24, 2003
    #5
  6. Joseph Ellis

    Joseph Ellis Guest

    On Thu, 24 Jul 2003 11:00:42 -0500, (Tad
    McClellan) wrote:

    >Joseph Ellis <> wrote:
    >> On Thu, 24 Jul 2003 08:51:28 -0500, (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
     
    Joseph Ellis, Jul 25, 2003
    #6
  7. Joseph Ellis

    Joseph Ellis Guest

    On Thu, 24 Jul 2003 16:18:46 +0200, Malte Ubl <>
    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
     
    Joseph Ellis, Jul 25, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joakim Hove

    Lexical variables - speed penalty?

    Joakim Hove, Oct 7, 2004, in forum: C Programming
    Replies:
    3
    Views:
    263
    CBFalconer
    Oct 7, 2004
  2. Michal
    Replies:
    1
    Views:
    84
    Robert Klemme
    Aug 27, 2004
  3. Paul Lalli

    convention regarding lexical filehandles

    Paul Lalli, Jan 13, 2005, in forum: Perl Misc
    Replies:
    14
    Views:
    179
    Michele Dondi
    Jan 16, 2005
  4. Replies:
    5
    Views:
    111
  5. pgodfrin

    Style and subroutines in Perl Programs

    pgodfrin, Mar 13, 2008, in forum: Perl Misc
    Replies:
    8
    Views:
    132
    Michele Dondi
    Mar 13, 2008
Loading...

Share This Page