Re: Perl Programming guidlines/rules

[particle]

i think this list cramps style too much, to a point of hindering development. while i agree that following a good set of coding standards leads to easier maintenance, i don't think this is the best starting point.

maybe something like:

• style
• follow perlstyle, except as noted below
• do not shift subroutine arguments, use code like my( $self, $arg1, @args ) = @_; instead
• name SCALAR, ARRAY, and HASH variables in the singular, not plural
• use taint mode
• ...
• substance
• untaint all passed parameters
• log all errors/warnings, using #your log module here#
• use CGI to process CGI parameters
• use DBI to access database
• use HTML::Template for HTML templates, not HEREDOCs
• ...
• tests
• write tests for each subroutine
• test modules for pod, using Test::Pod
• test for documentation coverage, using Pod::Coverage
• test modules for version information, using Test::Version
• verify all tests pass before merging code and tests with development stream
• ...
• docs
• document each module with pod, sections include: your sections here
• enter Change Request #(s) in comment upon checkin to SCM repository
• all code must be in SCM repository before release to ...
• ...

but i could be completely off base. it's been a while since i've developed these standards (or followed them in a large team.)

~Particle *accelerates*

[Anonymous Monk]

do not shift subroutine arguments, use code like my( $self, $arg1, @args ) = @_; instead

May I ask why?

[particle]

honestly, it's a simple matter of style. i prefer the look of it. i have a habit of not destroying things when i don't have to, but that's not the real reason. really, i like declaring variables with a single my.

for some history on shift vs. @_, see tilly's Silly code reviews and shift, which started with How to pass a variable to function selected from a hash.

for a debate, see tadman's Shift versus Sanity

~Particle *accelerates*

[Anonymous Monk]

It's harder to screw up when adding variables. I've done my $this = shift then tried to change it to my ($this,$x) = shift if you start with my ($this) = @_; then my ($this,$my,$something,$asdfjkksaldf) = @_; will be less error prone

[particle]

unless, of course, you add your variables by

## start with:
my $foo = shift;

## adding $bar yields:
my $foo = shift; 
my $bar = shift;

it's a matter of style. if you're changing your style, it's safer to rewrite the code from scratch than to modify in place -- even (or especially) if it's only one statement.

~Particle *accelerates*

[hardburn]

Huh? I thought it was rather clear from the documentation that shift doesn't care if you're using list context. It just always takes the first element off an array and returns it. What made you think otherwise?

my $this = shift;
my $x = shift;
...

[Aristotle]

There's two cases I shift:

sub some_method {
    my $self = shift;
    my ($various, $other, $parameters) = @_;
}

and something like

sub process_list {
    my ($some, $positional, $params) = splice @_, 0, 3;

    for(@_) {
        # ...
    }
}

The first case is somewhat arbitrary and maybe a bit superstitious; I just like to consistently always shift off the $self when I'm writing OO code - something about that one parameter's significance makes it feel right to me.

The second case is plain and solid reasoning: I hate to name variables when I don't need to. Temporaries should always hold computed, not copied values, in my opinion. (You also have to work on @_ in case you wanted to modify the passed values - which of course is to be used seldomly and carefully and orthogonal to shifting.)

The second case is an exception of course though not exactly a red herring either.

So in general, I would agree; my (@variables) = @_; is preferred. There are good reasons not to, occasionally, however.

Makeshifts last the longest.