Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!sgi!daisy!cplai From: cplai@daisy.UUCP (Chung-Pang Lai) Newsgroups: comp.lang.postscript Subject: Re: indentation style Message-ID: <3855@daisy.UUCP> Date: 9 Feb 90 05:56:49 GMT References: <17807@rpp386.cactus.org> <9002040147.AA16999@en.ecn.purdue.edu> <45829@wlbr.IMSD.CONTEL.COM> <17880@rpp386.cactus.org> Reply-To: cplai@daisy.com (C. P. Lai) Organization: Daisy/Cadnetix Lines: 95 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.