develooper Front page | perl.perl5.porters | Postings from May 2000

Re: Thoughts on maintaining perl

From:
Chris Nandor
Date:
May 25, 2000 10:54
Subject:
Re: Thoughts on maintaining perl
Message ID:
p04310123b553150d6a27@[192.168.0.77]
At 13.31 -0400 2000.05.25, Horsley Tom wrote:
>Just some examples: perl has about 1,247 levels of operator
>precedence, and some fools out there actually insist
>on minimizing the number of parens in any expression
>by picking || instead of OR, etc. No ordinary human
>being can actually parse crap like that - I'd much
>rather have the "ugly" parens cluttering things up just
>so I'd know, not only what the expression really means,
>but what the author really meant when he wrote it,
>in some ways APL is more readable :-).

If you cannot understand this:

    if ($x == 1 || $y == 2) {

then I don't know what to say.  I just cannot fathom how that is hard to
read.  On the other hand, if you think this is hard to read:

    my $mode =
        (ref $hash->{CALLBACK} eq 'CODE'
            ? kAEQueueReply
            : (exists $hash->{REPLY}    # check event setting
                ? $hash->{REPLY}
                : exists $self->{REPLY} # check global setting
                    ? $self->{REPLY}
                    : 1                 # default to wait
            )
                ? kAEWaitReply
                : kAENoReply)

            | (exists $hash->{MODE}
                ? $hash->{MODE}
                : exists $self->{MODE}
                    ? $self->{MODE}
                    : (kAECanInteract | kAECanSwitchLayer));

well, then I deserve the flogging I get for it.  :-)  But it is not the
lack of parens that make it hard to read (or the ugliness of the constants,
which I won't address, blame Apple if you'd like to), it is the complexity
of the statement.  It should be broken up for better readability.  I put
this here to show that I don't think it is so much parens that are a
problem as often as it is a programmer's unwillingness to break up a
complex statement into smaller statements.  I understand this unwillingness
somewhat, since I clearly have fallen prey to it myself, as above.

But at least I have some useful comments, right?

And note that again nothing above has anything to do with Perl, aside from
the fact that it happens to be written in Perl.  The only reason I wouldn't
write something this ugly in C is because I am not comfortable enough in C
to be that ugly.  But I am sure I could if I set my mind to it.

I did format the above code so it is readable to me and to perhaps others,
but then I think I came up with a good rule of thumb: if you have to spend
more time thinking about how to format it for readability than you did
thinking about how to code it in the first place, then it probably needs to
be rewritten.

I might just leave this code in Mac::Glue for as a reminder to myself, however.


>You may get the idea: You can be a perfectly competent
>programmer, writing perfectly wonderful perl code
>and it can *still* be virtually impossible for someone
>else to maintain.

I dunno, I am not sure I buy it.  Can you give us an example of
well-written Perl code that would be very difficult for another reasonably
competent Perl programmer to maintain?

-- 
Chris Nandor       |     pudge@pobox.com      |     http://pudge.net/
Andover.Net        | chris.nandor@andover.net | http://slashcode.com/



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