Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!woody
From: woody@rpp386.cactus.org (Woodrow Baker)
Newsgroups: comp.lang.postscript
Subject: Re: indentation style
Summary: indentions
Message-ID: <17878@rpp386.cactus.org>
Date: 7 Feb 90 05:19:23 GMT
References: <17807@rpp386.cactus.org> <9002040147.AA16999@en.ecn.purdue.edu> <45829@wlbr.IMSD.CONTEL.COM>
Organization: River Parishes Programming, Plano, TX
Lines: 75

In article <45829@wlbr.IMSD.CONTEL.COM>, mh@awds26.eaton.com (Mike Hoegeman) writes:
> I've written a fair amount of postscript (of the NeWS flavor)
> so just thought I'd put in my two cents worth here.
> 
> In article <17872@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
> >> >						  However, I don't
> >> >recommend following his brace style, as it is a bit hard to read.
> >> 
> >> 
> >> 	/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
> 
> In theory, I agree with you on the above comment. However in practice
> I'd have to side with Glenn on not putting the brace on it's own line.
> I started out putting opening braces on their own line but when i
> started writing large chunks of code it seems to balloon into nothing
> but a bunch of lines with braces and a few lines of code in between.
> 
> > 
> >> 	% sample 2 (which yours should have been):
> >> 
> >> 	/stuff
> >> 	{
> >> 		asdfasdfasdf
> >> 		asfasfasdfasf
> >> 	} def
> >
> 
> 
> >Not quite:
> >it should have been 
> >	/stuff
> >			{
> >			asdfasd
> >			sadsdfgg
> >			} def
> 
> Why is this better than % sample 2 above ?? (now don't get hostile
> this is a genuine question :-) )
The reason, is the tabbing of the opening curly brace, and the indention
level of the 2 body lines.e
> To me the style directly above very much confuses ...
> 
> 	- what exactly the contents of the executable array are
> 	(i.e. the braces are harder to pick out)

Good point.  I often do an indent on the body of code bracketed by
the braces, depending on whether or not there is a lot of code.

> 	you've been distracted enough that you have to scan
> 	back and remember , Oh yeah the /stuff that was 
It is faster and easier than visualy hunting for hidden braces.
I have prepared a follow up article that I am going to post today, that
perhaps better explains things.  I spent 20 min fooling around with
VI, trying to get it to quit dropping characters, and to quit moving
tabs and indents around, when I was posting the reply, and thus left
out some things that should have been in there.  I used my mouse drien
editor (Charles Crowleys PT, and got it cleaned up)

> 
I'd love it.  I don't have FTP, so either it needs to be posted or emailed
Cheers
Woody