NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/perl/5927

Internet Message Format | 1992-09-14 | 10.1 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!uwm.edu!psuvax1!rutgers!micro-heart-of-gold.mit.edu!eddie.mit.edu!minya!jc
From: [e-mail] (John Chambers)
Newsgroups: comp.lang.perl
Subject: Re: Perl language formatting conventions?
Message-ID: <[e-mail]>
Date: 14 Sep 92 20:46:46 GMT
References: <[e-mail]> <[e-mail]>
Distribution: comp
Lines: 196

In article <[e-mail]>, [e-mail] (Larry Wall) writes:
> In article <[e-mail]> [e-mail] (John Chambers) writes:
> :
> : It has always seemed to me that a single tab is the best indent.  That
> : way,  the  reader  can choose his/her own favorite indent spacing, and
> : everyone is happy.  (In vi you type "se ts=4" to  get  4-column  tabs;
> : most editors have a similar command.) It's also very fast to type.

> That's fine if nobody but you ever has to look at the file, and you
> never have to print it.  It's also fine if you editor translates to
> standard 8-space hard tabs for you on input and output.  But if your
> editor is going to do that, why not just disconnect the notion of soft
> tab stops from hard tab characters?  In vi you just set sw=4 and learn
> to use ^T instead of TAB.  (Mind you, I'd've made TAB work like ^T
> does, and DEL/BACKSPACE like ^D, just so people couldn't use the
> laziness argument to avoid ^T/^D.  Then make some way to insert a hard
> tab if you want one.  One could almost do it with a keyboard mapping.)

My main reason for not doing this is  that  I  don't  understand  what
you're talking about.  I tried it, and frankly, I can't make sense out
of what vi is doing when I type ^T or ^D.  The first ^T seems to  move
over  the  width  that  I  set sw to; subsequent uses of ^T seem to do
nothing, except that sometimes they freeze the editor so I have to use
^C  to  get  it to accept any more commands.  ^D's behavior is totally
incomprehensible to me; I can't even describe sensibly what  it  does.
Do you perhaps have a different version of vi than I do?

On the other hand, ":se ts=4" is simple:  it sets  the  tab  stops  to
every 4 columns, and the tab key moves over just like you'd expect. As
for printing, pr has options to set the tab positions,  as  do  pretty
much all formatters I've ever seen. (Now if only stty had a way to set
tab stops on the (virtual) terminal, so my (rare) uses  of  cat  would
work correctly.  ;-)

> : It's about as wrong a convention as one  could
> : come up with (so of course it's the most common one ;-).

> That's the point.  Yes, it's just a convention to be broken, but civil
> disobedience always has a price.  What I balk at, of course, is when *I*
> have to pay the price for *your* civil disobedience.  Then it's no longer
> mere civil disobedience.  More like disturbing the peace, or maybe
> dictatorship of the proletariet.  :-)

Huh?  It seems to me that using tabls is the most  cooperative  method
that  I  could use.  It makes it easy for any reader (who knows how to
set tab stops on  the  output  device  ;-)  the  freedom  to  use  any
indentation  that  he/she  pleases.  How could I be more sociable than
that?  On the other hand, any method that uses spaces (whether or  not
mixed  with  tabs)  forces the writer's conventions on the reader, and
makes the output look garbled  to  a  lot  of  readers,  until  he/she
figures out how you had your tabs set, and changes to match that.

> I don't mind squabbling over mere cultural differences as long as we
> realize that's all we're doing.  Certainly, I've learned to deal with
> the other sort of file--look at the retab script in the book, after all.
> Note that the default is to translate 8 spacing to 4...  :-)

Yup; one of the most important functions of the net  is  to  encourage
violent debate over trivia.  Ain't it fun?  Of course, my main fear is
that I may have sinned by  mentioning  a  specific  editor,  and  thus
invited the wrath (and followups) of partisans of those Other Editors.

> : The next most difficult problem, of course, is  finding  the  boundary
> : between  declarations  and statements in a function (so that something
> : can be added there).  ...

> Yes, and you'll note that the distinction disappears again in C++.  Almost
> enough reason to switch right there...  :-)

Hey, I hadn't noticed that.  Good for them! Some of the changes  to  C
have  had  the  effect  of making it much more difficult to generate C
from a program. Perhaps C++ will be an improvement.  The relaxation of
the  need for a final ';' in perl 4.0.35 is a good example of a bit of
trivia that tremendously simplifies a lot of code-generating code. One
of  the  real sillinesses in C is that final ',' is sometimes optional
(in lists of initializers),  and  sometimes  forbidden  (in  parameter
lists),  while  the final ';' is required.  They couldn't have made it
much more difficult if they'd tried.

> : Actually, my favorite bit of nonsense in C formatting is  the  growing
> : practice  of what I call "Chinese" coding.  Recall that traditionally,
> : Chinese was written vertically, with one or two character per line.

> Well, I'm sure they think of the lines as vertical, not horizontal.
> More cultural differences.  It's just the column-major vs row-major
> fight all over again.  :-)

Yes; the idea is that much C  code  is  now  close  to  being  written
vertically, although the programmers don't think of it that way.

Actually, the Chinese system  was  mixed.   The  lines  of  text  went
vertically,  but agglutinated multi-character words went horizontally.
Thus, the symbol for Beijing was always two side-by-side symbols  (the
one  for  "north" and the one for "capital"), because this is a single
name consisting of two characters.  In the  modern  horizontal  style,
both go horizontally. This is not a win for readability, as it entails
a loss of useful information.

> This is becoming an unfortunate necessity.  The only alternatives I see are

In some cases, perhaps.  But code fragments like:
    }
        else
    }
are pretty much inexcusable. The amount of text that I can examined at
once  is pretty much limited to what I can fit into a window, and this
sort of coding practice effectively minimizes what fits into a window.
It  thus  cuts  down  on  the  amount of code that I can see (and thus
understand) at any given time.   A  reader-friendly  programmer  would
condense  these  three lines to one, and increase by two the number of
lines that will fit in a window.

>     1) Go back to simpler problem spaces and simpler solution spaces.

In many cases, "divide and conquer" is still a useful approach.  As  I
recall,  it  was  Al  Einstein who suggested that everything should be
made as simple as possible, but no simpler.  (I wonder if this was his
original concept, or if he got it from someone else.)

>     2) Use shorter, less mnemonic names and consequently suffer more
>         confusion and name collisions.

This depends. Perhaps it's my math background speaking, but very often
I  find  code  much  more  readable if the little local variables have
names like "i", "j", or "n", rather than things like "loop_counter" or
"current_line" or "number_of_items_left_to_do".

>     3) Put fewer but wider windows on the screen and blow off the
>         punchcard metaphor once and for all.

Very good idea.  But current coding practice would encourage a lot  of
tall,  skinny  windows.  You often need 50 or 60 lines to display what
could more easily be understood with half as many horizontal lines.

> ...  In Perl 5, I'm making => a synonym for comma, so you can
> say things like:
>     $childmess = &Get(
>             OC           => $oc,
>             OI           => $oi,
>             SCOPE        => $scope1,
>             ATTR_ID_LIST => $no_attrs);

> As someone pointed out earlier, all you do is stuff the list into an
> associative array, and then pull out the parameters in the order you
> like.  If you don't think this is a win, note that the actual
> &new_GetReq call has 14 arguments, but most of them have defaults or
> can be undefined:

This doesn't look like => is a synonym for a comma; it looks like  you
are using named (keyword) style parameters.  This strikes me as a Very
Good Idea ...  How soon can we all get this release?

> So, would you rather call &Get, or &new_GetReq?

Well, while I understand the need  for  more  complicated  names,  the
trouble  is  that  I  find it rather difficult to type things like the
latter correctly.  The sequence "_G" is especially awkward on a qwerty
keyboard.  And when writing X-Windows code, I often find that the only
way to get the names spelled right are to  cut  and  paste,  which  is
frustratingly  slow,  but faster than typing it wrong and not noticing
until the thing I typed  comes  up  undefined,  and  looking  for  the
undefined symbol but typing it wrong on the grep command ...

I don't think I'm the only one with this problem. I've looked over the
shoulder  of various people writing X code, and I've noticed that most
of them make heavy use of cut-and-paste to "type" the  names  of  many
things.   Most  of them also use "man -k" a lot to find the names that
they can't quite remember how to spell.  This is not a very  efficient
use of human time.

> ... And if you really
> detest vertical alignment, you often have a better chance to fit it
> onto one line with named parameters than with positional parameters:

>     $childmess = &Get(OC=>$oc, OI=>$oi, SCOPE=>$scope1, ATTR_ID_LIST=>$no_attrs);

> Shoot, almost made it...  :-)

Sounds like a win to me. Actually, I think it'd be more readable, more
mnemonic, and might even fit, if you used ':' instead of '=>'. Perhaps
that's another bit of trivia that could be worth a violent argument or
three.  Would this conflict with other uses of ':'?

So when will version 5 be released to the unsuspecting world? Should I
not bother upgrading to 4.whatever.35?

--
All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc
--
Pensu tutmonde; agu loke.
--
All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc
--
Pensu tutmonde; agu loke.