NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/perl/5558

Internet Message Format | 1992-08-27 | 7.0 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!network.ucsd.edu!news!netlabs!lwall
From: [e-mail] (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: coding style (was Re: Perl language formatting conventions?)
Message-ID: <[e-mail]>
Date: 27 Aug 92 18:00:29 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NetLabs, Inc.
Lines: 170
Nntp-Posting-Host: scalpel.netlabs.com

In article <[e-mail]> [e-mail] (Todd Ogasawara) writes:
: In article <[e-mail]> [e-mail] (Larry Wall) writes:
: >In article <[e-mail]> [e-mail] (David Wuertele) writes:
: >: What do youse all think?
:
: >That's a religious issue.
:
: >There's only one sure-fire way to be happy.  Do what you know is right,
: >and don't expect everyone to like it.
:
: >Larry
:
: I agree with Larry's 2nd statement but am not sure I agree with the first
: totally. I admit that "style," by its very nature, has some degree of
: individualism. However, I suspect that there might be some way to quantify
: some (though not all) aspects of coding style to help programmers make
: source code easier for other people to read and interpret (or, for that
: matter, for the programmer him/herself at some time in the future).

Well, okay.  I can see that my first statement was misleading.  People
often use the statement as a copout to mean there is no right or
wrong.  But those who know me well know that I have some very definite
ideas about right and wrong.  I was merely trying to say that such
discussions tend to be non-productive, because people are generally
more interested in maintaining their cultural continuity than in
improving their lives.

: There were a few journal articles a number of years back trying to
: determine how varying indentation size affects code readability (I think
: the conclusion was that 4 spaces on a "standard" sized screen was optimal
: though I still prefer 8 spaces :-).

Ah, is that cultural continuity or mere laziness?  I would consider it false
laziness because for a small mental investment you can generally make your
favorite editor do 4 spaces as easily as 8 (or nearly as easily), and reap
a Laziness Benefit every time you DON'T have to figure out where to
split a line because your indentation no longer manifests an unhealthy
affinity for the right margin.

Perceptually--yes, a dangerous word to address to someone in the Psych
Dept.--perceptually, I think 4 spaces has all the benefits of 8.
Anything less than that and I have trouble lining things up on the
screen.  But the half spacing for line continuations is easy to calculate
(2), and easy to see because such lines are right next to each other.
(Not that I feel bound to use 2 spaces if some other spacing lines things
up nicely.)

: There must also be some way to use some of the findings from vision
: on processing simple (curved vs. angular) and complex (alphanumeric and
: ideographic) images as a tie-in to things like parentheses placement.

Yes!!!!  That's why I did the quoting mechanisms the way I did!!!!

    s/foo/bar/

but

    s(/foo)(/bar)

I despise the overly minimalistic Unix cultural "ideal" of imitating a
row of leaning toothpicks: s/\/X\/Y\(\*\)/\/Y\/X\1/.

Sure, s/// can typically turn into s### or whatever.  In Perl, so can
m//, tr///, q//, qq// and qx//.

But there's something particularly special about m(), qx[], etc. and I think
you've put your finger on it.

Visual distinction is why I like

    for (;;) {
    }

and

    $_ = <FOOHANDLE>;

What people often don't realize is that Visual Distinction is an aid to
Mental Laziness, which is a Virtue.  (LISPers take note.)

: One thing I've found over the past few years is that I and some other
: people find placing a space after an openning paren and before a closed
: paren sometimes adds to the readability of the code (this is not a 100%
: rule, it is more like an "i before e except after c except in receive"
: rule).

No, "receive" follows the rule.  It's "weird" that is weird.

: E.g., (from C)
:
:     while ((c = getc(fpIn)) != EOF) {
:         putc(c,fpOut);
:     }
: vs.
:     while ( ( c = getc(fpIn) ) != EOF ) {
:         putc(c, fpOut);
:     }
:
: Note that the "paren space" rule is not used 100% of the time in even a
: short piece of code like the one shown above.

Yes, sometimes I do that, and sometimes not.  Though generally NOT on
something like a condition, which already has spaces outside the parens.
But I'll often say FROBNERZ( foobar + boofar ); and such.  It really
depends on the degree of perceived clutter.

: I also think that the use of parens even when they aren't needed (like the
: example above) aids readability. I.e., the code above is equivalent to
:
:     while ( ( c = getc(fpIn) ) != EOF )
:         putc(c, fpOut);

You meant curlies/braces?  I required curlies in Perl because people wrongly
perceive this sort of thing:

     while ( ( c = getc(fpIn) ) != EOF )
         putc(c, fpOut);
        count++;
    printf("%d\n", count);

This is also why I prefer outdenting the trailing curly.  If you say,
as some do for reasons that they have recently admitted are related
to cultural continuity,

     while ( ( c = getc(fpIn) ) != EOF ) {
         putc(c, fpOut);
        count++;
        }
    printf("%d\n", count);

then you're actually trying to ignore the existence of the trailing curly,
and relying on the indentation for grouping.  Why else would you line
it up except to make it more or less invisible?  You might as well go the
typical LISP route and save a line of text:

     while ( ( c = getc(fpIn) ) != EOF ) {
         putc(c, fpOut);
        count++;}
    printf("%d\n", count);

But if you say, as I would,

     while ( ( c = getc(fpIn) ) != EOF ) {
        putc(c, fpOut);
        count++;
    }
    printf("%d\n", count);

then the trailing curly Intrudes upon your consciousness, and says
"I AM HEREBY TERMINATING THIS BLOCK ON MY SOLE AUTHORITY."  I like that.
I like closed structures, and what Ada calls "comb" structures.  Then
again, I like classical Greek, and they liked to construct sandwich
sentences too.

: Well, as I said I agree with Larry's second point. I don't expect everyone
: to agree with what I've said above. I would be interested to hear what
: other people think about ways to apply style rules to make Perl and other
: kinds of source code easier to read.

I find myself writing things like this lately:

    if    (/^h/)        { &help }
    elsif (/^m/)        { &mod  }
    elsif (/^u/)        { &up   }
    elsif (/^d/)        { &down }
    elsif (/^scope/)    { &scope }
    elsif (/^s/)        { &sib  }
    elsif (/^r/)        { $redraw = 1 }
    elsif (/^trace/)    { &rc('on *_trace') }
    elsif (/^q/)        { last  }
    else                { print qq/I don't know how to "$_", boss!\n/ }

That probably just means I need to add a case statement to Perl.  But the
minimalist in me rebels.  :-)

You want religion, I got religion...

Larry