Style and subroutines in Perl Programs

Discussion in 'Perl Misc' started by pgodfrin, Mar 13, 2008.

  1. pgodfrin

    pgodfrin Guest

    Greetings,

    I've browsed the Camel book and perldoc.perl.org about style in a
    program and I was wondering what most people think.

    I'm in the habit of the following pseudo-code structure of my programs
    (or are they scripts :) ):

    0. shebang and comments
    1. Use statements
    2. 'global' variables or constants
    3. INIT or BEGINs
    4. Subroutine definitions
    5. main program, using a "MAIN:" label (just so I can find it)
    6. an exit; statement
    7. END code

    I've seen some code where the subroutines are placed after the "main"
    program - this way (my way) seems logical to me, but short of starting
    a war of opinion, I was wondering what others thought about the
    placement of subroutines?

    regards,
    phil g
     
    pgodfrin, Mar 13, 2008
    #1
    1. Advertising

  2. On Mar 13, 1:19 pm, pgodfrin <> wrote:
    > Greetings,
    >
    > I've browsed the Camel book and perldoc.perl.org  about style in a
    > program and I was wondering what most people think.
    >
    > I'm in the habit of the following pseudo-code structure of my programs
    > (or are they scripts :) ):
    >
    > 0.  shebang and comments
    > 1.  Use statements
    > 2.  'global' variables or constants
    > 3.  INIT or BEGINs
    > 4.  Subroutine definitions
    > 5.  main program, using a "MAIN:" label (just so I can find it)
    > 6.  an exit; statement
    > 7.  END code
    >
    > I've seen some code where the subroutines are placed after the "main"
    > program - this way (my way) seems logical to me, but short of starting
    > a war of opinion, I was wondering what others thought about the
    > placement of subroutines?


    I prefer sticking the subs at the end. So if I open a file, i can look
    at the main body of the code, and see what's going on immediately
    rather than being thrust into low level subroutines, and having to
    search for the main body.
     
    nolo contendere, Mar 13, 2008
    #2
    1. Advertising

  3. pgodfrin

    smallpond Guest

    On Mar 13, 1:19 pm, pgodfrin <> wrote:
    > Greetings,
    >
    > I've browsed the Camel book and perldoc.perl.org about style in a
    > program and I was wondering what most people think.
    >
    > I'm in the habit of the following pseudo-code structure of my programs
    > (or are they scripts :) ):
    >
    > 0. shebang and comments
    > 1. Use statements
    > 2. 'global' variables or constants
    > 3. INIT or BEGINs
    > 4. Subroutine definitions
    > 5. main program, using a "MAIN:" label (just so I can find it)
    > 6. an exit; statement
    > 7. END code
    >
    > I've seen some code where the subroutines are placed after the "main"
    > program - this way (my way) seems logical to me, but short of starting
    > a war of opinion, I was wondering what others thought about the
    > placement of subroutines?
    >
    > regards,
    > phil g



    TMTOWTDI
     
    smallpond, Mar 13, 2008
    #3
  4. pgodfrin

    Guest

    pgodfrin <> wrote:
    > Greetings,
    >
    > I've browsed the Camel book and perldoc.perl.org about style in a
    > program and I was wondering what most people think.
    >
    > I'm in the habit of the following pseudo-code structure of my programs
    > (or are they scripts :) ):
    >
    > 0. shebang and comments


    The shebang has to be first if it is going to be meaningful.
    Comments go where ever the thing that needs commenting is.
    On some scripts, there are comments right after the shebang line
    giving the purpose of the script as a whole. But if there is
    a usage message, then I don't also include comments with the same
    info.


    > 1. Use statements


    If the module being used supports only one sub or code-section and is
    unlikely to be useful outside that context, then the use statement goes in
    the sub it supports. Otherwise it goes up near the top. (use strict and
    use warnings go right up after shebang/purpose.)


    > 2. 'global' variables or constants
    > 3. INIT or BEGINs


    If the INIT or BEGIN supports a well-defined sub-set of the code, then it
    goes with the code it supports. Same with END blocks. Otherwise
    I usually put BEGIN blocks before the "use"s, other than strict and
    warnings, because I might want whatever BEGIN does to happen before the
    modules are run.

    > 4. Subroutine definitions


    I generally put the subroutines after the main code. This was drilled into
    me by a teacher who was a big advocate of "top-down" programming. It
    always seemed kind of silly to me, because tying the lexical order of the
    code to the temporal order of its planning/conceptualization seemed to be
    such weak symbolism as to be trivial. But it has mostly stuck with me
    anyway. If I am taking over someone else's code and they put the
    subroutines first, I rarely take the effort to rearrange it. If you are
    into B&D, then your order has the advantage that perl will not compile
    subroutines using lexical variable names that are "my"ed in the main body
    of code. With the other order you can get away this sin (provided the main
    code is at file scope.)

    > 5. main program, using a "MAIN:" label (just so I can find it)


    Do you put the main program in a "bare" block just so you can label it like
    this? I'd just use a comment, # MAIN:, instead of adding a spurious scope.

    > 6. an exit; statement


    I usually don't use unconditional exit statements. I just let it fall of
    the end of the code and exit that way. If the code is so messy that it
    is not obvious where the end of the file-scope-level code is, and I don't
    want to take the time to clean it up at the moment, then I might add an
    unconditional exit just as a reminder.


    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    The costs of publication of this article were defrayed in part by the
    payment of page charges. This article must therefore be hereby marked
    advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    this fact.
     
    , Mar 13, 2008
    #4
  5. pgodfrin

    pgodfrin Guest

    On Mar 13, 1:15 pm, wrote:
    > pgodfrin <> wrote:
    > > Greetings,

    >
    > > I've browsed the Camel book and perldoc.perl.org about style in a
    > > program and I was wondering what most people think.

    >
    > > I'm in the habit of the following pseudo-code structure of my programs
    > > (or are they scripts :) ):

    >
    > > 0. shebang and comments

    >
    > The shebang has to be first if it is going to be meaningful.
    > Comments go where ever the thing that needs commenting is.
    > On some scripts, there are comments right after the shebang line
    > giving the purpose of the script as a whole. But if there is
    > a usage message, then I don't also include comments with the same
    > info.
    >
    > > 1. Use statements

    >
    > If the module being used supports only one sub or code-section and is
    > unlikely to be useful outside that context, then the use statement goes in
    > the sub it supports. Otherwise it goes up near the top. (use strict and
    > use warnings go right up after shebang/purpose.)
    >
    > > 2. 'global' variables or constants
    > > 3. INIT or BEGINs

    >
    > If the INIT or BEGIN supports a well-defined sub-set of the code, then it
    > goes with the code it supports. Same with END blocks. Otherwise
    > I usually put BEGIN blocks before the "use"s, other than strict and
    > warnings, because I might want whatever BEGIN does to happen before the
    > modules are run.
    >
    > > 4. Subroutine definitions

    >
    > I generally put the subroutines after the main code. This was drilled into
    > me by a teacher who was a big advocate of "top-down" programming. It
    > always seemed kind of silly to me, because tying the lexical order of the
    > code to the temporal order of its planning/conceptualization seemed to be
    > such weak symbolism as to be trivial. But it has mostly stuck with me
    > anyway. If I am taking over someone else's code and they put the
    > subroutines first, I rarely take the effort to rearrange it. If you are
    > into B&D, then your order has the advantage that perl will not compile
    > subroutines using lexical variable names that are "my"ed in the main body
    > of code. With the other order you can get away this sin (provided the main
    > code is at file scope.)
    >
    > > 5. main program, using a "MAIN:" label (just so I can find it)

    >
    > Do you put the main program in a "bare" block just so you can label it like
    > this? I'd just use a comment, # MAIN:, instead of adding a spurious scope.
    >
    > > 6. an exit; statement

    >
    > I usually don't use unconditional exit statements. I just let it fall of
    > the end of the code and exit that way. If the code is so messy that it
    > is not obvious where the end of the file-scope-level code is, and I don't
    > want to take the time to clean it up at the moment, then I might add an
    > unconditional exit just as a reminder.
    >
    > Xho
    >
    > --
    > --------------------http://NewsReader.Com/--------------------
    > The costs of publication of this article were defrayed in part by the
    > payment of page charges. This article must therefore be hereby marked
    > advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    > this fact.


    Thanks Xho - very good observations. What is B&D ?
    pg
     
    pgodfrin, Mar 13, 2008
    #5
  6. pgodfrin

    Guest

    pgodfrin <> wrote:
    >
    > Thanks Xho - very good observations. What is B&D ?


    "bondage and discipline", originating from some salacious/erotic activity.

    In a programming context, it is slang to refer to highly rigid languages or
    philosophies that force you to obey "good practices" or highly structured
    programming, even when some compromise on those standards might be
    convenient (and even when such compromise would lead to better code, some
    would argue).

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    The costs of publication of this article were defrayed in part by the
    payment of page charges. This article must therefore be hereby marked
    advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    this fact.
     
    , Mar 13, 2008
    #6
  7. pgodfrin

    pgodfrin Guest

    On Mar 13, 2:49 pm, wrote:
    > pgodfrin <> wrote:
    >
    > > Thanks Xho - very good observations. What is B&D ?

    >
    > "bondage and discipline", originating from some salacious/erotic activity.
    >
    > In a programming context, it is slang to refer to highly rigid languages or
    > philosophies that force you to obey "good practices" or highly structured
    > programming, even when some compromise on those standards might be
    > convenient (and even when such compromise would lead to better code, some
    > would argue).
    >
    > Xho
    >
    > --
    > --------------------http://NewsReader.Com/--------------------
    > The costs of publication of this article were defrayed in part by the
    > payment of page charges. This article must therefore be hereby marked
    > advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    > this fact.


    k - got it...I got into the habit of putting the subroutines first so
    I didn't need to "forward declare". But I'm beginning to think that
    you really don't need to anyway...
    pg
     
    pgodfrin, Mar 13, 2008
    #7
  8. pgodfrin wrote:
    > On Mar 13, 2:49 pm, wrote:
    >> pgodfrin <> wrote:
    >>
    >>> Thanks Xho - very good observations. What is B&D ?

    >> "bondage and discipline", originating from some salacious/erotic activity.
    >>
    >> In a programming context, it is slang to refer to highly rigid languages or
    >> philosophies that force you to obey "good practices" or highly structured
    >> programming, even when some compromise on those standards might be
    >> convenient (and even when such compromise would lead to better code, some
    >> would argue).

    >
    > k - got it...I got into the habit of putting the subroutines first so
    > I didn't need to "forward declare". But I'm beginning to think that
    > you really don't need to anyway...


    You don't really need to but if the subroutines are defined first then
    they can be called without using parentheses like Perl's built-in operators.

    sub my_sub { return "In my_sub" }

    print my_sub;


    However if they are defined at the end then parentheses are required:

    print my_sub();

    sub my_sub { return "In my_sub" }


    You could also declare the subroutines at the start and then define them
    later:

    sub my_sub;

    print my_sub;

    sub my_sub { return "In my_sub" }



    John
    --
    Perl isn't a toolbox, but a small machine shop where you
    can special-order certain sorts of tools at low cost and
    in short order. -- Larry Wall
     
    John W. Krahn, Mar 13, 2008
    #8
  9. On Thu, 13 Mar 2008 10:19:34 -0700 (PDT), pgodfrin
    <> wrote:

    >I've seen some code where the subroutines are placed after the "main"
    >program - this way (my way) seems logical to me, but short of starting
    >a war of opinion, I was wondering what others thought about the
    >placement of subroutines?


    The advantage of putting them at the beginning is that they will be
    known as the main program is compiled and you can e.g. skip some
    parens. Alternatively you can place them at the end, and use
    declarations.


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, Mar 13, 2008
    #9
    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. Replies:
    12
    Views:
    1,705
    Dave Thompson
    Jan 10, 2005
  2. Ken Varn
    Replies:
    0
    Views:
    539
    Ken Varn
    Apr 26, 2004
  3. Joseph Ellis
    Replies:
    6
    Views:
    147
    Joseph Ellis
    Jul 25, 2003
  4. Casey Hawthorne
    Replies:
    14
    Views:
    470
  5. doni
    Replies:
    6
    Views:
    297
    Ch Lamprecht
    Mar 7, 2007
Loading...

Share This Page