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
Aristotle Pagaltzis
April 2, 2010 15:50
Re: RFC: Perl manual pages -- update to follow the perlstyle.podguidelines
Message ID:
* Tom Christiansen <> [2010-04-02 23:00]:
> Second, being paren-stingy is dangerous in several ways. It's
> harder to read, it's harder on beginners, and it's harder to
> maintain.

Since we’re talking about myths, I’ll nominate this; on par with
the claim that `and` and `or` should be reflexively preferred
over `&&` and `||`.

> Omitting parentheses wherever one can creates a nightmare for
> whoever has to maintain that code.

<Doctor>Don’t do that then.</Doctor>

From the fact that obessively omitting all optional parentheses
makes code harder to read does not follow that neurotically
adding parentheses everywhere is any better.

Instead I prefer a fairly paren-free style in which expressions
are homogenous in how each component of the expression binds; ie
expressions that do not mix operators of different precedence
levels (maybe two of them, if there is a repeating pattern),
a series of maps and greps vertically separated, or a stack of
list ops (cf. point-free), or such. If I need a lot of parens
(especially nested parens), to me that means I’m trying to write
an overly heterogenous and therefor complex expression: it should
be broken out into separate statements.

On this basis, I deem

    my $str = sprintf '%02d', 1;

much better than the noisy alternative.

The most weighty consideration to me is to avoid nesting (or
else, as in point-free style, to nest all the way, identically,
without ceremony). Heterogenously nested code is very likely hard
to read no matter how you write it. It requires mental parsing.
Homongenous code can be visually pattern-matched.

> Text without distinctive syntactic markers is hard to arrange
> together in your head, whether it's program text or
> natural-language text, and for many reasons punctuation works
> much better for this than does non-punctuation.
> That's why
>    while crunch func alpha and func beta func gamma
>    begin
>         store next sum 1 last
>    end
> does not arrange itself into meaningful togetherness with anything
> like the speed with which this does:
>     while ( crunch(func($alpha)) && func($beta) && func($gamma) ) {
>         $next = 1 + $last;
>     }

Both forms annoy me. If I were writing this, it would bother
me. What I’d actually do would depend on a very large number of
factors, but if the situation was *exactly* as in the example, my
reaction would likely be this one:

    $next = 1 + $last
        while crunch func $alpha
        and          func $beta
        and          func $gamma;

I will sometimes write chained ternaries in similarly tabular
fashion. Tables good.

> Punctuation is your mind's friend: Eschew it at your own peril,
> but lead not the little children into that desolate sea of
> flavorless porridge full of silent syntactic snafus. It doesn't
> help anyone. It hurts them.

Minds aren’t all alike. Mine likes spatial arrangement much
better than squiggly lines.

*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
#Aristotle Pagaltzis // <>

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