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
From:
Jari Aalto
Date:
April 4, 2010 04:23
Subject:
Re: RFC: Perl manual pages -- update to follow the perlstyle.pod guidelines
Message ID:
87ochz4g3m.fsf@jondo.cante.net
Tom Christiansen <tchrist@perl.com> writes:

> and therefore the parens don't matter.  Removing them changes
> nothing and risks no confusion, so it seems cleaner without them.

Yes, I was referring to the "simple expressions" all the way. When
combining the expressions, that's another matter. But trivial cases I
think it's preferred still:

    for my $item (sort keys {$a <=> $b} %hash)      # without extra parens here

I agree everything you wrote. But, I think here:

>     close(FH) || die "can't close $path: $!";
>
> than ever, ever write:
>
>     close FH or die "can't close $path: $!";
>
> because close, FH, or, and die all have the same lexical nature: they're
> all idents.  That cascade of idents *really* bugs me.  My mind super really
> wants the () and the || to break things up for quick visual parsing.
> It takes me much, much longer to read 

It can be made visually distict by alternative means. You do not need to
type monotonic "one space" around every word:

    close FH or die "can't close $path: $!";          # bad

    close FH  or  die "can't close $path: $!";        # better

And when there is enough room even:

    close FH    or   die "can't close $path: $!";     # There is no doub here of LEFT and RIGHT

Similarly in conditionals to make the groups stand out:

    if ( defined $flag   or   $a == 100   or   ord $char == ... )

compared to:

    if ((defined $flag) || ($a == 100) || (ord($char == ...)))

Jari


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About