Front page | perl.perl5.porters |
Postings from April 2010
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 <h.m.brand@xs4all.nl> 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. ;-)
Abigail
Thread Previous
|
Thread Next