develooper Front page | perl.perl5.porters | Postings from April 2010

Re: RFC: Perl manual pages -- update to follow the perlstyle.pod guidelines

Thread Previous | Thread Next
Aaron Sherman
April 3, 2010 16:52
Re: RFC: Perl manual pages -- update to follow the perlstyle.pod guidelines
Message ID:
On Fri, Apr 2, 2010 at 3:57 PM, H.Merijn Brand <> wrote:

> As Tom said, and and or are no safer than && and ||, they just have a
> different precedence. The `safer' part is when parens are left out
>  open (FOO, "foo.txt") || die $!;      OK
>  open  FOO, "foo.txt"  || die $!;      Wrong
>  open (FOO, "foo.txt") or die $!;      OK
>  open  FOO, "foo.txt"  or die $!;      OK

That certainly does look safer to me, yep. I think the problem is that
seasoned Perl programmers often know when they are and aren't getting
themselves into ambiguous territory. I don't think the claim of safety is
really aimed as such folks. Me, I can never remember anything about
precedence no matter now many times I read the perl source - a symptom of a
cognitive dyslexia that I've never had adequately diagnosed. Thus, I'm
forever stuck as a newbie. :(

Point is, safer can be interpreted as "someone who doesn't know or can't
keep track of what they're doing is less likely to smash someone in the
skull with it."

>   return if ($a && $b) || ($c && $d);
>  =
>  return if $a && $b or $b && $c;
> better? not sure. Esp when I deparse I get confused:

I see this problem fairly often. People interpret the presence of and and or
as some kind of a warning AGAINST using parens to disambiguate visually (not
grammatically) ambiguous code. People who read them this way need to be
corrected in the docs, plain and simple.

My rule of thumb on and/or vs &&/|| is this:

Use &&/|| when you have a single relationship, even for several values,
between variables or constants. For example:

 $a && $b && $c

Use and/or to chain simple comparisons as above:

 ($a && $b && $c) or $d

In such cases, when there is a complex expression on either the left or
right hand side, prefer to enclose it in parens for clarity.

Whenever combining &&/and with ||/or, use parens to disambiguate (note, the
above rules force you to do this most of the time anyway):

 $a and (($b && $c) or $d)

And in a more general sense, I've always included your rule as a fallback:

Personally I prefer to use 'and' and 'or' to separate expressions from
> actions:
>  expression and action;
>  $a eq "yes" or return;

> >     - Improve readability, that is encourage use of whitespace where
> >       applicaple. Both vertical and horizontal between tokens.
> As said, whitespace doesn't always make things easier to read.
> Sometimes it makes things harder to read.

I think the key bit there was "when applicable." For example:

      map { sum( @{$_}[0,1] ) } @things );

In general, my rule here is:

Spaces after any ( or { or [ and before the matching token where the
contents of the subscript, invocation or block are not a constant value or
simple variable ("$foo[1][$bar][ $n+7 ]")

Newline+indent after ( and any subsequent commas whenever the contents would
force the programmer to wrap the line
 Corollary: Never vary the number of function arguments per line.

If the above rules don't make it readable, re-write into multiple

> Parens are not bad at all. They force the eye to group things that are
> to be grouped. They take away ambiguity.
Sometimes. But sometimes we need to keep the fingernail clippings to a

> There is more than one way to do it. Coding is art. I don't think perl
> coding style should be strict.

There is a world of difference between providing a uniform coding style in
the docs for the user's sake and enforcing a global coding style on Perl

That said, I coding style guideline for a language often frees more
developers than it enslaves. I know that at many companies, I've been able
to argue successfully against the imposition of one developer's sense of
aesthetics being imposed on everyone if the language we were using had a
simple and relatively relaxed coding style extant.

Interestingly, Python's isn't too bad in terms of the ground it covers,
though it has tumors that result from their elevation of whitespace to
first-class syntax.

> > How to proceeed then?
> 1. Don't try to do all what you suggest at once.


> 2. Discuss each and every step before you propose a patch.

This makes busy-work for everyone. Why is it useful? Sure, discussion of the
broad strokes makes sense, but every detail?

> 3. Accept the decision of the group

Yes, the Perl community is all about bending like a reed in the wind of
consensus... ;-)

> 4. Wait till 5.12 is out :)

Not sure how to interpret that smiley. Do you really think this work should
wait? You have an eager contributor, here, who wants to improve the lot of
their fellow developers...

Aaron Sherman
Email or GTalk:

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About