🚀 go-pugleaf

In article <17880@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
>A particularly odious example is found on page 74 of the GREEN book.
> 
>/SH {%def
>        dup stringwidth pop >        currentpoint 3 1 roll
>        add 300 gt { %if
>            72 exch 48 sub dup 36 lt { %if
>               showpage
>               pop 700
>            }if
>            moveto
>        }{ %else
>            pop
>        }ifelse
>        show
>}bind def        
> 
>This code suffers from the following problems:
> 
>1. The { that matches the first }if is hidden at the end of the line
>        72....

Woody has an obsession for matching curly braces.  All his complaints
will disappear if he can accept a new convention.  I am used to
Glenn's (or C style).  You don't match {}, hear that Woody?  You
match indentation.  The first }if in Glenn's program line up with
the line 72, it tells me right away that the } closes the line
starting with 72.  I don't even bother to look for the {.

>2. a quick look at the code, would lead you to match the }if
>   brace with the { after the gt.  (If you can even find it)

Again, this won't happen if you are matching indentation.  Can
you forget about the { for a moment?

>3. it is not obvious what the }{ leading '}' here matches.  You
>   have to work your way back up, line at a time to find that it
>   matches the '{' after the gt.

It is 110% obvious that the } matches the line "add 300"  I didn't
even spend a second finding the {, I can tell you right away.
If you use Glenn's method, you'd probably change your criteria
to a 10 second rule.  Obviously, you can save alot of time if
you stop looking for the {.

>5. The comments are meaningless, and confuse the issue.

The comments are very useful for those who have an addiction on
matching {}.  And it provides an easy cross checking to verify
if the indentation is done right.

>It is compact in both the horizontal and vertical directions.

This is the most important property.  The more compact the code
stay together, the less you have trouble reading the structures
of the program.

[ Woody's ugly looking example deleted ] :-)

>This code has the following drawbacks, if you could call them that.
> 
>It takes more vertical space than the prior code.
>It takes more horizontal space than the prior code.

I won't use your style just because of those.  When the tokens and
lines are spreaded so far apart, you don't see the nested structure
as easily as Glenn's style.

>It has the following advantages.
> 
>1. You can instantly find any pair of curly braces.  Just scan down
>   the column under the brace.

I couldn't care less for this.  I don't looks for {.  Even if I have
to, my editor (vi) matches them for me.

>2. The procedure name is clearly set off by it's self.  It can
>   be found easily in a larger program.
>3. The controlling test for the if and ifelse can be instantly found.
>4. Comments line up neatly in the same vertical column on the right.
>5. Related operators are grouped together.
>6. It passes the 15 second rule.

Glenn's style also has the same advantage if you can stop looking for
{'s.

This is kind of like a religious war.  I don't mind reading codes in
either style as long as it is consistent.  After I read the first
block of code, I'll match indentation if it is written in Glenn's
style.  I can also switch to match {} if it is written in Woody's
style.  I'll hate matching {} though, because matching indentation
is much easier to do.

The worst you can have is the mixed style, it will drive you crazy.
I will definitely vote for Glenn's style.