Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Style and subroutines in Perl Programs

Reply
Thread Tools

Style and subroutines in Perl Programs

 
 
pgodfrin
Guest
Posts: n/a
 
      03-13-2008
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
 
Reply With Quote
 
 
 
 
nolo contendere
Guest
Posts: n/a
 
      03-13-2008
On Mar 13, 1:19*pm, pgodfrin <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
smallpond
Guest
Posts: n/a
 
      03-13-2008
On Mar 13, 1:19 pm, pgodfrin <(E-Mail Removed)> 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
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      03-13-2008
pgodfrin <(E-Mail Removed)> 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.
 
Reply With Quote
 
pgodfrin
Guest
Posts: n/a
 
      03-13-2008
On Mar 13, 1:15 pm, (E-Mail Removed) wrote:
> pgodfrin <(E-Mail Removed)> 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
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      03-13-2008
pgodfrin <(E-Mail Removed)> 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.
 
Reply With Quote
 
pgodfrin
Guest
Posts: n/a
 
      03-13-2008
On Mar 13, 2:49 pm, (E-Mail Removed) wrote:
> pgodfrin <(E-Mail Removed)> 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
 
Reply With Quote
 
John W. Krahn
Guest
Posts: n/a
 
      03-13-2008
pgodfrin wrote:
> On Mar 13, 2:49 pm, (E-Mail Removed) wrote:
>> pgodfrin <(E-Mail Removed)> 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
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      03-13-2008
On Thu, 13 Mar 2008 10:19:34 -0700 (PDT), pgodfrin
<(E-Mail Removed)> 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,
 
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
Subroutines and Callbacks in Perl/Tk doni Perl Misc 6 03-07-2007 09:12 PM
Book: Higher-Order Perl: Transforming Programs with Programs Casey Hawthorne Perl Misc 14 07-14-2005 06:43 PM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM
References and subroutines ReaprZero Perl 1 12-04-2003 02:53 PM
Style question regarding subroutines and lexical variables Joseph Ellis Perl Misc 6 07-24-2003 11:37 PM



Advertisments