glenn@heaven.woodside.ca.us (Glenn Reid) (02/06/90)
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 wrong. Here are the two styles that I recommend, the first one slightly preferable, to me, because it saves one vertical line in the program. Readability also has to do with how much of a given context you can see at once without scrolling, and vertical spacing has a lot to do with that; the second sample is what I think yours should have looked like, since the code inside the braces is what should be indented, not the braces themselves. % sample 1: /stuff { %def asdfasdfasdff asdfasdfasdf } def % sample 2 (which yours should have been): /stuff { asdfasdfasdf asfasfasdfasf } def Indentation has semantic meaning. It means, roughly "everything indented the same amount is at the same structural level." In the case that you show, the name "stuff" (you forgot the slash, by the way) is at the same level as the procedure body, which you indent. I find that very hard to read, since "stuff" is now hanging out on the left all by itself. It gets worse when you nest them several deep. 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 it in the Introduction somewhere. And, of course, if you want to take issue with it on the net, that's fine, but please say something substantive, other than it should be done like anyone would indent Pascal, and please at least get the stuff right that you are critiquing. Thanks, Glenn Reid
woody@rpp386.cactus.org (Woodrow Baker) (02/06/90)
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
mh@awds26.eaton.com (Mike Hoegeman) (02/07/90)
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 :-) ) 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) - what is being done with it. once you pick out with your eyes the executable array contents (OK, function body) you've been distracted enough that you have to scan back and remember , Oh yeah the /stuff that was standing out there by itself must be the name that is getting bound to this function. It's not all that bad with a simple function declaration but with lots of ifelse's and case statements and whatnot it's yuck-o. I'll stop now since i'm probably getting quite incoherent. p.s. there is an indent type program that was posted a while back to comp.windows.news that does a really good job fixing up ungodly PostScript it can be configured a couple different ways depending on your tastes. if there is interest I'll repost it (or a t least direct you to how to get it) -mike.
woody@rpp386.cactus.org (Woodrow Baker) (02/07/90)
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
woody@rpp386.cactus.org (Woodrow Baker) (02/07/90)
Here are some examples, that I hope will help.
I have recieved several reqests for my address, in reference to the Password
resetter. It seems that I must not have included it or something:
Woody Baker
Rt.1 Box I
Manor, Tx. 78653
Concerning programming styles:
Glenn, don't take this personally, but....
A particularly odious example is found on page 74 of the GREEN book.
AS WRITTEN:
/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....
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)
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.
4. related operations are not grouped together.
5. The comments are meaningless, and confuse the issue.
6. The function name does not stand out clearly by it's self.
It has the following advantage, if you can call it that.
It is compact in both the horizontal and vertical directions.
It should be re-written like this:
%
% comments about the function, it's parameters, and what it does.
%
/SH
{
dup stringwidth pop
currentpoint 3 1 roll add
300 gt % related operations
{
72 exch 48 sub % related operations
dup 36 lt % related operations
{
showpage
pop 700 % related operations
}if
moveto
}
{
pop
}ifelse
show
}bind def
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.
It has the following advantages.
1. You can instantly find any pair of curly braces. Just scan down
the column under the brace.
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.
Another problem snippet
/MS { % multiple "show"
counttomark 2 idiv {
0 moveto show
}repeat pop
mark
}bind def
In this case, a look at the code, causes you to match the curly brace
just after the MS with the brace in front of the repeat. This sends you
off hunting for the control for the repeat loop. The hidden { is
amost impossible to see. Now, if this was hidden inside several more
blocks like this, and especially, if this define was nested inside of
a conditional, you could spend a lot of time analyzing the code in order
to understand it.
datastuff targetvalue eq {
/MS { % multiple "show"
counttomark 2 idiv {
0 moveto show
}repeat pop
mark
}bind def
}{
1 1 moveto
}ifelse
While these are "style" issues, they have a much deeper impact. One should
program, not for oneself, but with the poor bugger who will follow you
in mind. Software Engineers rarely stay in one place long. You not
only wind up costing the company money after you are gone, but you also
wind up causing the next guy to curse and swear at you. Personally, I'd
like to line 3 particular software authors up who worked on the compiler
I have to maintain, and either see how many of them, I could kill with one
shot, or else get them between my headlights...
Cheers
Woody
p.s. Once again, the comments are not directed at GLENN. They are directed
at postscript programmers in general. The GREEN book just happend to be
a handy spot to grab the examples from. I don't recommend following
the style examples in the GREEN book, though otherwise the code is good.
tdcj@bar.ZK3.DEC.COM (Dave Jedlinsky OSEM) (02/08/90)
# Eat this, line eater! In article <17880@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > Concerning programming styles: > > Glenn, don't take this personally, but.... > A particularly odious example is found on page 74 of the GREEN book. > > AS WRITTEN: > > /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: > > [ 6 valid complaints deleted to save vertical space ] > > It should be re-written like this: > > % > % comments about the function, it's parameters, and what it does. > % > > /SH > { > dup stringwidth pop > currentpoint 3 1 roll add > 300 gt % related operations > { > 72 exch 48 sub % related operations > dup 36 lt % related operations > { > showpage > pop 700 % related operations > }if > moveto > } > { > pop > }ifelse > show > }bind def > In general, I agree with Woody's complaints about Glenn's preferred style. However, in an earlier message, Glenn also proposed an alternate style which I believe meets your criteria for readability, and I find is easier to read than the sample immediately above. Using the same procedure above, here is my preferred style: /SH % (string) SH - <- I think that is correct, but the idea is there. { dup stringwidth pop currentpoint 3 1 roll add 300 gt % related operations { 72 exch 48 sub % related operations dup 36 lt % related operations { showpage pop 700 % related operations } if moveto } { pop } ifelse show } bind def Following your guidlines, these are the advantages of this style: > 1. You can instantly find any pair of curly braces. Just scan down > the column under the brace. > 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. In addition: 7. You know what to put on the stack for the procedure, and what is there afterwards. Just look for the procedure name. 8. It makes more sense regarding nesting levels (which Glenn mentioned in the article where he proposed this alternate style). The curly braces cause the level to go one lower, but they themselves are on the higher level. (Does that make any sense?) 9. I like the way it looks. :-) > While these are "style" issues, they have a much deeper impact. One should > program, not for oneself, but with the poor bugger who will follow you > in mind. Software Engineers rarely stay in one place long. You not > only wind up costing the company money after you are gone, but you also > wind up causing the next guy to curse and swear at you. I agree wholeheartedly. I'll bet that a pretty printer could solve all these style complaints quite easily, though. Just filter any source code which you have to modify, and you will be able to read it in your preferred style. > Cheers, > Woody > p.s. Once again, the comments are not directed at GLENN. They are directed > at postscript programmers in general. The GREEN book just happend to be > a handy spot to grab the examples from. I don't recommend following > the style examples in the GREEN book, though otherwise the code is good. I fear that this discussion is about to get religious (as if it hasn't already). Note that there are relatively minor changes to Woody's code to bring it to what I consider the "proper" indentation style. In fact, it boils down to how far the braces should be indented and where the comment containing the arguments go. -David Jedlinsky Digital Equipment Corporation | He who dies with the most toys is dead. dcj@decvax.dec.com | ...!decwrl!decvax!dcj | . . . . . . . . . . . . . . inews fodder
ralerche@lindy.Stanford.EDU (Robert A. Lerche) (02/08/90)
Might I suggest...
/name
{ line 1
line 2
etc...
} def
Similarly...
condition
{ line 1 of true
...
}
{ line 1 of false
...
} ifelse
etc. This style (braces lined up with each other and outside indentation)
is nice for C, too...
if (condition)
{ line 1 true ;
line 2 true ;
}
else
{ line 1 false ;
line 2 false ;
}
I never will understand the attraction of braces that don't line up with
each other.woody@rpp386.cactus.org (Woodrow Baker) (02/09/90)
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 > > etc. This style (braces lined up with each other and outside indentation) > is nice for C, too... > > if (condition) > { line 1 true ; > line 2 true ; > } > else > { line 1 false ; > line 2 false ; > } > > I never will understand the attraction of braces that don't line up with > each other. I never will either, but I also don't understand the attraction for braces that aaren't indented within thier controlling code. Lining them up as the above example, is lots better than not lining them up, but they really should be indented for ease of reading. The normal reading pattern is from left to right, not down the page. By indenting the braces, you are moveing left to right, so it is easier to track. You also move down the page as well, but there is the normal, and natural (western) movement from left to right. I'd imagine that certain Oriental languages that read from top to bottom, would tend to encourage vertical braces as in the above example. Cheers Woody s
glenn@heaven.woodside.ca.us (Glenn Reid) (02/09/90)
In article <17880@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >Glenn, don't take this personally, but.... >A particularly odious example is found on page 74 of the GREEN book. Of course I'll take it personally. You called my indentation style "odious". Let me make a few points, because I think there are some things being missed, then I'll shut up, for the greater good: 1. The opening brackets are not "lost", they are always at the end of the line (with or without a trailing comment). If the brackets ever had code following them, I would agree with you. % OK: currentpoint pop 72 lt { %ifelse showpage }{ %else 0 0 moveto } ifelse % not OK: currentpoint pop 72 lt { showpage }{ 0 0 moveto } ifelse 2. I'm not wedded to that indentation style, as I have pointed out. It does, however, have a reasonable tradeoff of readability versus code space, which is why I chose it for the green book. It is also not odious or horrible nor does it cause birth defects. It would behoove you to learn to read it instead of complaining about it, because there is a lot of it in the world. 3. Comments like %if help enormously to know what the open brace is going to be closed by. You can call them "meaningless" and "confusing to the issue", but when you have a lot of nested braces and some of them cross pages, you simply can't live without the comments. 4. You should look at the INDENTATION (read white space), not at the curly braces. If you scan vertically down a column until you something that is no longer at the same level of indentation (white space), you can assume a sub-structure. Scanning a little further, you'll see the closing brace, and you'll know what the structure was. Seeing the open brace doesn't tell you much anyway, unless there's a comment. It's pretty easy, once you see it. The key point is NOT to look at the curly braces, but to look at the white space. 5. Please don't include the entire text of an article when you follow up. This is basic net etiquette. Please subscribe to news.announce.newusers or whatever it's called. 6. I subscribe to the other technique with everything but {'s: gsave mydict begin 0 0 moveto (test) show end grestore What this boils down to, I guess is that you can't read my code very easily. That's fine, but don't flame me for it. I can read yours. How does this sound: "while Woody occasionally has something interesting to say, I don't recommend following the style examples that he posts to the net. While these are style issues, they have a much deeper impact. One should program, not for oneself, but with the poor bugger who will follow you in mind (or who will read your book)." You should recognize those words, because they're yours. But this time, they're pointed back at you. >p.s. Once again, the comments are not directed at GLENN. They are directed >at postscript programmers in general. The GREEN book just happend to be >a handy spot to grab the examples from. I don't recommend following >the style examples in the GREEN book, though otherwise the code is good. OK, I'll bite. I DO recommend following the style examples in the GREEN book. Take your pick. There. I'm done taking it personally. Please realize that if you don't want people to think you're sniping at them, you should be careful to just provide information, rather than supplying opinions. You got better about that on the indentation issue (when pressed by me) but it started out as just "Folks, I don't like that style, so don't use it." People really don't care who thinks what, they want to learn, and they learn by example, and by ideas. Glenn
cplai@daisy.UUCP (Chung-Pang Lai) (02/09/90)
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.
glenn@heaven.woodside.ca.us (Glenn Reid) (02/09/90)
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.
delong@frith.egr.msu.edu (02/10/90)
Myself, I like a hybrid of a couple of those styles. It leaves the
name hanging, reduces the ease of accidental deletion of a brace, and
keeps the braces lined up (so you can see them without code getting
in the way).
/name
{
line 1
line 2
etc ...
} def
condition
{
line 1 of true
line 2 of true
etc ...
}
else
{
line 1 of false
line 2 of false
etc ...
} ifelse
Keith
delong@frith.egr.msu.edu
Delta Collegemike@ntmtka.mn.org (Mike Tietel) (02/10/90)
I believe this religious indentation war has gone on quite long enough.
Indentation is a matter of personal taste and opinion. However, you
must be able to adapt to and tolerate other styles, unless you want to
spend much of your time reformatting someone else's code and/or
reinventing the wheel. Despite the fact that I am not of oriental
ancestry and do not speak or read any oriental languages, I find the
following styles more intuitive and probably practiced by more programmers:
/name {
} def
or
/name
{
} def
But remember, "Opinions (read: coding styles) are like *ssholes:
everyone's got one, and every one else's stinks".
--
Mike Tietel
Northern Telecom, Inc. (612) 932-8017
9701 Data Park, H-200 mike@ntmtka.mn.org
Minnetonka, MN 55343 {rosevax,bungia}!ntmtka!mikewoody@rpp386.cactus.org (Woodrow Baker) (02/20/90)
In article <6382@cps3xx.UUCP>, delong@frith.egr.msu.edu writes: > Myself, I like a hybrid of a couple of those styles. It leaves the > name hanging, reduces the ease of accidental deletion of a brace, and > keeps the braces lined up (so you can see them without code getting > in the way). > > /name > { > line 1 > line 2 > etc ... > } def > > condition > { > line 1 of true > line 2 of true > etc ... > } > else > { > line 1 of false > line 2 of false > etc ... > } ifelse > > I like this one a LOT. it is clean and readable. Cheers Woody
rcd@ico.isc.com (Dick Dunn) (02/21/90)
woody@rpp386.cactus.org (Woodrow Baker) writes: > delong@frith.egr.msu.edu shows yet another indentation style. ... > I like this one a LOT. it is clean and readable. the only disadvantage being that it's not the way the rest of the world writes PostScript. But that's OK, right? -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Don't lend your hand to raise no flag atop no ship of fools.