Re: gtk2-perl: moving on by standardizing our code

[Ed Halley <ed halley cc>]

Perhaps distribute a .perltidyrc which would approximate your desired
standard style?  It's a 90% solution, but that's better than a poke in
the eye with a sharp stick.

Some comments on your "open questions" below, from a heavy Perl user
(though I'm not one of the commit-rights folks for this project).


On Wed, 2003-03-12 at 14:40, Guillaume Cottenceau wrote:
> 1. do we use infix "if/unless" or "and/or" for short control
>    structures? namely:
>        $self->set_active($flag) if @_ == 2;
>                 or
>        @_ == 2 and $self->set_active($flag);

When one uses "and" this way, one is employing statement-like side
effects in just a part of an expression.  Benign thing AND statement. 
It doesn't read like English.  (Larry Wall is avoiding the keywords
'switch' and 'case' in perl6 because they don't read like English.)

I prefer the trailing 'if' metaphor, but I prefer "if not" over
"unless".  When the body is big enough to obscure the 'if' at a glance,
that's when it's time to do it properly with curly braces and
indentation and everything.

> 2. for one-lines, do we use `shift' or do we name the parameters
>    using $_[0], $_[1], etc? I don't have an opinion here. Using
>    `shift' can be better because then you can use @_ for the
>    parameters of the functions, with any number of parameters.

I've seen either for this case, and propose it stays fluid:  use
whichever seems more appropriate at the time.  If you're writing an
adapter and want to rob the arguments first, use shift.  If you're
selecting a few arguments to pass on, use indices.  Generally, if your
sub is so small that named lexical arguments are overkill, then you may
not want to use shift.

However, in full-fledged subs, when the argument list isn't highly
flexible with different types (similar to C++ overloading) I do prefer
the self-documenting idiom of using named argument slots via either one
of the following:

    sub foo
    {
       my ($x,$y,@z) = @_;
    }
    sub bar
    {
       my $x = shift;
       my $y = shift;
       my $z = @_;
    }

> 3. do we use "return" at the end of functions? I'd choose not
>    (it's useless) but most people don't like that, it seems.

I far prefer the clarity of using 'return' on the tail statement, for
all but the one-liners which are more akin to C's #define macros. 
Again, it's the difference between statement and expression:  if you
want your caller to get something, then use the 'return' statement.

-- 
[ e d @ h a l l e y . c c ]