Style and subroutines in Perl Programs

[pgodfrin]

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

 

[nolo contendere]

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.

 

[smallpond]

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

 

[xhoster]

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.

 

[pgodfrin]

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.


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


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.


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


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.


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

 

[xhoster]

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.

 

[pgodfrin]

"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

 

[John W. Krahn]

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

 

[Michele Dondi]

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