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

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

Thread Previous | Thread Next
April 10, 2010 09:14
Re: RFC: Perl manual pages -- update to follow the perlstyle.podguidelines
Message ID:
On Fri, Apr 02, 2010 at 05:04:29PM -0400, Aaron Sherman wrote:
> 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."

I don't get this "safer" thing. And expression using 'and', '&&', 'or'
or '||' is either correct, or incorrect. There's no "unsafe - safe" scale.

> 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

The only rule I use is "think trice before mixing and/or with &&/|| in
the same expression". 

> 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 ]")

Horrid, IMO. 

    $foo [1] [$bar] [$n + 7];

Can't do that in Perl6, and that's enough reason to never ever want to
code in that language.

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

We don't have a coding style at $WORK either (and if we had, I'd probably
ignore it). Good thing about that is, that whenever I see a line of code,
I can almost always instantly see whether or not I wrote it. ;-)


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