Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!adobe!heaven!glenn
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: indentation style
Message-ID: <136@heaven.COM>
Date: 9 Feb 90 06:02:15 GMT
References: <17807@rpp386.cactus.org> <9002040147.AA16999@en.ecn.purdue.edu> <45829@wlbr.IMSD.CONTEL.COM> <17880@rpp386.cactus.org> <7941@lindy.Stanford.EDU>
Reply-To: glenn@heaven.UUCP (Glenn Reid)
Organization: Glenn Reid (at home), NeXT, Inc.
Lines: 96

In article <7941@lindy.Stanford.EDU> ralerche@lindy.Stanford.EDU (Robert A. Lerche) writes:
>Might I suggest...
>
>	/name
>	{	line 1
>		line 2
>		etc...
>	} def
>
>Similarly...
>
>	condition
>	{	line 1 of true
>		...
>	}
>	{	line 1 of false
>		...
>	} ifelse
>
>I never will understand the attraction of braces that don't line up with
>each other.

The main reason for not putting { on the same line as some of the code,
in my opinions, is that you can not easily add and delete lines of code
without careful rearranging of the { delimiters.  You are far more likely
to avoid accidental deleting or rearranging of a { if you don't put code
after it.  Consider your first procedure, and the task of adding a line
to the beginning of the proc (or, analogously, deleting that line):

	/name
	{	new line 1
		line 2
		etc...
	} def

If the bracket were not on the same line as any part of the procedure
body, then you can easily add and delete lines without disturbing the
syntactic balance of the { }:

	/name
	{
		new line 1
		line 2
		etc...
	} def

In fact, I evolved the style that puts the brace up with "/name" after
many, many hours of programming, many of which introduced bugs into the
code.  Having an unbalanced { } somewhere in hundreds of lines of code is
extremely hard to find, since the interpreter will collect them in a
balanced fashion but will complain somewhere at the end of the file.
By contrast, if you add a line of code that has a bug in it, you can
usually find that line of code pretty quickly.

Just more opinions about indentation....

I kind of agree with you that the braces should line up, but I don't like
wasting the extra line.  Your proposal gets the line back, but at a
greater cost, in my humble opinion.  I'd rank them like this:

% best balance of space-efficient/readable/maintainable
	/name { %def
		line 1
		line 2
	} def

% most maintainable and most readable, a little space-inefficient
	/name
	{ %def
		line 1
		line 2
	} def

% readable, space-efficient, a little tricky to maintain:
	/name
	{	line 1
		line 2
	} def

% least readable and maintainable:
	/name
		{ line 1
		line 2
		line 3
		} def

But then again, I've learned to adapt.  The only thing that I've found
impossible to read is Apple's LaserPrep code, with due apology.

Glenn

Note:  The Adobe file server has a program that fixes indentation,
somewhat like Stan Switzer's program (I guess).  I think it is
called "psformat".  Of course, it fixes it according to my preference,
although you can reconfigure it to get the second style in this list,
too.