🚀 go-pugleaf

In article <133@heaven.COM>, glenn@heaven.woodside.ca.us (Glenn Reid) writes:
> In article <17867@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
> >p.s.  You should also get the GREEN book.  It has a LOT of things to say
> >about this and other topics.  It really is a philosophy book about
> >programming.  Glenn did an excellent job on it.
> 
> Thank you.
> 
> >						  However, I don't
> >recommend following his brace style, as it is a bit hard to read.
> 
> I have to take issue with you.  Here's what you wrote:
> 
> 	stuff{
> 	asdfasdfasdff
> 	asdfasdfsadf
> 	} def
> 	^^^^^^^^^^^^^^^^^^NONO.
> 
> 	stuff
> 		{
> 		asdfasdfasfd
> 		asdfasdfffdadsf
> 		} def
> 	^^^^^^^^^^^^^^^^^^^Much easier to see.  You are started on the right
> 	format.
> 
> 
> The first was supposed to represent my indentation style, but doesn't.  It
> isn't indented at all, in fact.  Even if one were to put the opening
> brace on a line by itself, as you propose, you still have the indentation

You are right here.  I failed to indent the to lines of code, and left the
'/' off.  it should have been written line this
j

> 
> 	/stuff { %def
> 			sdfasdfasdff
> 		a	sdfasdfasdf
> 	} def
> 
>

This has 2 problems.  The first is that you have to hunt for the opening
curly brace.  When you are several levels deep in nesting, and don't have an
editor that matches braces, it is exasperating.  The second problem
involves the comment. It is to easy to overlook.  You follow the Indian Hill
'C' style, which I totaly disagree with, as being hard to read.
I like to be able to see the procedure names at a glance, with the code
clearly lined up under a brace, and the procedure name hanging off by it's
self.
a
 
> 	% sample 2 (which yours should have been):
> 
> 	/stuff
> 	{
> 		asdfasdfasdf
> 		asfasfasdfasf
> 	} def

Not quite:
it should have been

	/stuff
			{
			asdfasd
			sadsdfgg
			} def

> 
> 
> 
> The other thing that is important in indentation style is to be able to
> easily skip past an entire context, from open to close, by just looking
> vertically down a column.  I think that all of these techniques do pretty
> well at that, although I have a natural preference for my own style :-)
> 
> Also, recognizing that this is "stylistic" is very important.  You claim
> that mine is "hard to read", but you don't offer any reasons for that,
> other than that you can't read it.  In the Green Book there is a modest
> amount of explanation of the indentation style and the rationale behind

Hidden curly's and buried comments are hard to pick out at a glance.  My
rule of thumb, both for 'C' and postscript, is that I should be able
to look at a procedure, for no more than 15 seconds, and find all indentions,
comments, curly's and variable defs.  If I can't, then
1. The function is to long.
2. The function is not indentedp roperly, or the style is obtuse.

doing something like

variable 0 eq {
	stuff
	stuff
}{
	stuff
	stuff } ifelse

or
variable 0 eq {
	stuff
	stuff }{
	stuff
	stuff }ifelse
should be grounds for drawing and quartering the previous progammer.
True, Postscript winds up being throwaway sort of code, but preambles,
and applications have to be maintained.  Don Lancaster, is perhaps the
most blatant abuser of style in the postscript world.  It usualy takes
me 15 or 20 min of work, to clean up even the simplest of his routines.
He does it that way, so save column space, so I understand the reason, but
IT still costs $15 - $20 worth of time to clean the stuff up.
The ripple impact of hard to read code, in terms of dollars wasted in time
spent trying to work the kinks out, is in general ignored by most programmers.

I don't  want to get this group off on discussions of style, or philosophy
but it does impact code quite a bit.

We can certainly agree to disagree on style, and for the record, I find
your programming style difficult to follow and read.  It violates my 15 second
rule.  Please understand, that I have a great deal of respect for your
work howver.  The Green book, IMHO should be the FIRST book that any
beginning postscript programmer should read.  It should be read with the
RED book as a ref. for language constructs.  It is also a very good book
on programming philosophy in general, and I thank you for writing it.

Cheers
Woody