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

[Guillaume Cottenceau <gc mandrakesoft com>]

Ed Halley <ed halley cc> writes:

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

That could help, but the aim is that we do commit correct code at
first place :).
 
> > 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.)

That's a fair point.

Let's at least explain my point of view better :). I had told
only one reason, when actually there are three reasons I prefer
"and" over "if":

- "if" is a so short word that when the statement on the left is
  rather long, I don't notice the "if" at first glance (that
  doesn't happen for infix "foreach", I think this is because the
  word is much longer)

- "condition and statement" reads in the same order than
  "if (condition) { statement }"; it's more logical to have the
  same order for all forms

- "statement if condition" has a reversed logic, a.k.a
  "condition" is first evaluated, then "statement" is run if the
  condition is met; each time I read it, my mind is disrupted by
  that fact (the readability is decreased)

Note again that if the majority of committers prefer the infix
"if", of course I'd agree - I just want that we use the same code
style everywhere.
 
> I prefer the trailing 'if' metaphor, but I prefer "if not" over
> "unless".

Personally, I have a rather strong fear of "unless", that I find
really unreadable. Even if we decide to use the infix "if", I'd
really hope we not use "unless". "if not" could be nice.

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

Yes, of course, agreed :).

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

My aim is to have an uniformity, but you may be right that in
that field it would be more negative than positive.
 
> 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

Yes.

> of the following:
>
>     sub foo
>     {
>        my ($x,$y,@z) = @_;
>     }
>     sub bar
>     {
>        my $x = shift;
>        my $y = shift;
>        my $z = @_;
>     }

Second form has no advantage? It wastes two lines and is probably
even less readable.
 
> > 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.

Well, you use a circular argument here :).

I personally don't have any trouble with the missing "return" on
the last statement. For me, a function's value has the value of
the last statement, I don't see why it shouldn't. Here, we are
polluted by imperative languages, Pascal's procedures, or even by
C's obligation to use "return". Perl has more functional features
than those languages, and a statement always "returns" (has) a
value, hence there is no point in using "return".

But here again, that may be too far from "standard" Perl and most
committers may prefer using "return"?


-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/