From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Perl language formatting conventions?
Date: 12 Sep 92 20:37:52 GMT
Distribution: comp
Organization: NetLabs, Inc.

In article <1361@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
: 
: > I also use 4-space indent, in case you hadn't noticed.  :-)
: 
: 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.)

: One of the silliest frustrations is all the programmers  who  like  to
: use  mixtures  of  tabs  and spaces to get 4-column spacing with 8-col
: tabs. This forces readers to reset the tabs to 8 columns to make sense
: of  the  code;

Eek.  Talk about cultural differences...

: it is slow for the writer to type;

No.  Not with sw=4 and ^T and autoindent.

: it wastes disk space and network bandwidth.

A somewhat valid point, but I sincerely doubt that most of your disk is
taken up with source code.  And much long haul traffic nowadays is
compressed such that the way you tab your lines doesn't matter.

: 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.  :-)

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...  :-)

: 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).  What's frustrating here is that the  original  C
: compiler  allowed declarations to be mixed with statements (as long as
: everything was declared before it was used),  so  the  problem  didn't
: exist.   The  modern  "improvement"  requiring  that declarations come
: before statements made  the  job  much  more  difficult,  and  for  no
: apparent  reason  that I've ever heard.  It certainly doesn't make the
: compiler's job any easier.  (Yes, I *have* written compilers; I  won't
: listen  seriously to any claim that this affects the compiler-writer's
: job materially.  ;-)

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

: 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.  :-)

: We are now seeing a lot of C in a similar style:
: 
:     if (!initf)
:     {
:     	win = 
: 	    XCreateSimpleWindow(
:     		display,
:     		RootWindow(display,screen),
:     		win_x,win_y,
:     		win_w,win_h,
:     		border_width,
:     		WhitePixel(display,screen),
:     		Pixel(display,screen)
:     	    );
:     	initf = TRUE;
:     }
:     	else
:     {
:     	(void*)
: 	fprint(
: 	    stderr,
:     	    "%d *** %s can't create new window [%d=%s].\n"
:     	    timestamp(),
:     	    progname,
:     	    errno,
:     	    sys_errlist[errno]
:     	);
:     }

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

	1) Go back to simpler problem spaces and simpler solution spaces.
	2) Use shorter, less mnemonic names and consequently suffer more
		confusion and name collisions.
	3) Put fewer but wider windows on the screen and blow off the
		punchcard metaphor once and for all.

My basic policy is, of course, to use one line or maybe two, until it
starts looking cluttered, and then switch to the vertical format.  (The
vertical format actually works better in languages that have named
parameters.  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:

    sub Get {
	local(%arg) = @_;
	&new_GetReq(
	    defined($arg{ID}) ? $arg{ID} : &new_id(),
	    $arg{DELETE_CB},
	    $arg{SOURCE} || *def_source,
	    $arg{DEST} || *def_dest,
	    $arg{QOS} || *def_qos,
	    $arg{MODE},
	    $arg{APP_CONTEXT},
	    $arg{OC},
	    $arg{OI},
	    $arg{ACCESS},
	    $arg{SYNC},
	    $arg{SCOPE} || *def_scope,
	    $arg{FILTER} || *def_filter,
	    $arg{ATTR_ID_LIST});
    }

So, would you rather call &Get, or &new_GetReq?  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...  :-)

Larry