in reply to Perl Programming guidelines/rules

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:

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*

Replies are listed 'Best First'.
Re: Re: Perl Programming guidlines/rules
by Anonymous Monk on Nov 21, 2002 at 20:16 UTC
    do not shift subroutine arguments, use code like my( $self, $arg1, @args ) = @_; instead

    May I ask why?

[reply]
[reply]
[d/l]
      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
[reply]

        unless, of course, you add your variables by 

        ## start with:
my $foo = shift;

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

        [download]

        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*

[reply]
[d/l]
[select]

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

        [download]
[reply]
[d/l]
Re^2: Perl Programming guidlines/rules
by Aristotle (Chancellor) on Nov 27, 2002 at 16:05 UTC
    There's two cases I shift: 
    sub some_method {
    my $self = shift;
    my ($various, $other, $parameters) = @_;
}

    [download]
    and something like 
    sub process_list {
    my ($some, $positional, $params) = splice @_, 0, 3;

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

    [download]

    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.

[reply]
[d/l]
[select]

In Section Meditations