edw@IUS1.CS.CMU.EDU (Eddie Wyatt) (03/17/88)
Way back whenever, someone posted a list of thou shall and thou shall not.
One item on that list was asymmetric layout of assignment. Its use was
mainly to help the reader to distinguish assignment for equality
testing. I've adopted a convention related to that topic
that others may find useful and thought I'd share it with all of
you. (I'm such a nice guy :-))
In code segments that contain a lot of assigments, align the equal
signs. Example :
cosyaw = cos(rotate[YYAW]);
sinyaw = sin(rotate[YYAW]);
cosroll = cos(rotate[RROLL]);
sinroll = sin(rotate[RROLL]);
cospitch = cos(rotate[PPITCH]);
sinpitch = sin(rotate[PPITCH]);
/* x - axis */
yp = point[YY]*cosroll - point[ZZ]*sinroll;
zp = point[YY]*sinroll + point[ZZ]*cosroll;
point[YY] = yp;
point[ZZ] = zp;
/* y - axis */
zp = point[ZZ]*cospitch - point[XX]*sinpitch;
xp = point[ZZ]*sinpitch + point[XX]*cospitch;
point[XX] = xp;
point[ZZ] = zp;
/* z - axis */
xp = point[XX]*cosyaw - point[YY]*sinyaw;
yp = point[XX]*sinyaw + point[YY]*cosyaw;
point[XX] = xp;
point[YY] = yp;
becomes:
cosyaw = cos(rotate[YYAW]);
sinyaw = sin(rotate[YYAW]);
cosroll = cos(rotate[RROLL]);
sinroll = sin(rotate[RROLL]);
cospitch = cos(rotate[PPITCH]);
sinpitch = sin(rotate[PPITCH]);
/* x - axis */
yp = point[YY]*cosroll - point[ZZ]*sinroll;
zp = point[YY]*sinroll + point[ZZ]*cosroll;
point[YY] = yp;
point[ZZ] = zp;
/* y - axis */
zp = point[ZZ]*cospitch - point[XX]*sinpitch;
xp = point[ZZ]*sinpitch + point[XX]*cospitch;
point[XX] = xp;
point[ZZ] = zp;
/* z - axis */
xp = point[XX]*cosyaw - point[YY]*sinyaw;
yp = point[XX]*sinyaw + point[YY]*cosyaw;
point[XX] = xp;
point[YY] = yp;
Easier to read no?
--
Eddie Wyatt e-mail: edw@ius1.cs.cmu.edug-rh@cca.CCA.COM (Richard Harter) (03/17/88)
In article <1136@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > .... A message praising the merits of aligning = signs in assignments vertically. It is my opinion, and sometimes practicing style that vertical alignment is a *good* thing. Another example is in declarations, e.g. struct athing **ptr; /* Say what ptr is */ struct bthing *aptr; /* Another explanation */ char c; /* Names all start in same col */ char *cc; /* And are alphabetized in type */ int i; /* Types sorted by name length */ And so on. However there is a problem with assignments that Eddie does not mention -- indentation can mess up the alignment by runing over the assignment column. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
mls@whutt.UUCP (SIEMON) (03/17/88)
In article <1136@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > > In code segments that contain a lot of assigments, align the equal > signs. Example : [ omitted ] > > Easier to read no? > -- > > Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu No. Or rather, not necessarily. It depends a great deal on the total layout of the page of code in question. I agree that there are lots of times when a few lines of code may want to override a "locally optimal" placement of the assignment token to match another (or more than one) nearby code segment. The message conveyed, subliminally, is a (loose) semantic coupling of the aligned segments. But such an implied coupling may convey the wrong message. One reason I dislike "pretty-printers", despite their ability to catch indentation errors, is that I like to redraft my code for just such spacing considerations as you suggest -- but the spacing decisions are _visually_ context-sensitive, with a context of (at least) the full page of text involved. One aspect of Knuth's "literate programming" is attention to such details. A very good analogy is the printing or engraving of music manuscripts. In _Goedel, Escher, Bach_, Hofstat[d?]er mentions the example of Chopin etudes to illustrate that each of this series has a distinctive visual personality and in consequence a dimension of meaning in addition to its sound. Bach's autographs (or Mozart's or whosesoever) have a similar "feel" that supports the performer in realizing the composer's intentions. Code similarly has, or should have, a similar dimension in communicating with programmers -- at the very least with those who maintain our code. ALL aids to communication are useful, and used well can greatly enhance the degree of intelligence we bring to our work. Michael L. Siemon contracted to AT&T Bell Laboratories ihnp4!mhuxu!mls (Disclaimer: I don't think anyone in AT&T reads my code)
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (03/18/88)
> It is my opinion, and sometimes practicing style that vertical alignment > is a *good* thing. Another example is in declarations, e.g. > > struct athing **ptr; /* Say what ptr is */ > struct bthing *aptr; /* Another explanation */ > char c; /* Names all start in same col */ > char *cc; /* And are alphabetized in type */ > int i; /* Types sorted by name length */ Of course another thing to keep in mind is that not every site or every user believes that "tabs every 8" is a universal truth. That's what the article looked like when I read it, and it failed to convince me that this format was better than the original. (You should see how some people's fancy .signature lines appear :-)
aglew@ccvaxa.UUCP (03/21/88)
> In code segments that contain a lot of assigments, align the equal >signs. Example : > >Easier to read no? > >Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu No, at least not by me. I have trouble determining which LHS goes with which RHS when there is so much blank space around. Now, I used to have a terminal that would have made it easier to read - it was missing every baseline ;-}
wes@obie.UUCP (Barnacle Wes) (03/25/88)
In article <1136@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > In code segments that contain a lot of assigments, align the equal > signs. Example : > cosyaw = cos(rotate[YYAW]); > sinyaw = sin(rotate[YYAW]); > > becomes: > > cosyaw = cos(rotate[YYAW]); > sinyaw = sin(rotate[YYAW]); > > Easier to read no? Whoops, you've slightly mis-spelled something there. That last sentence should read: Easier to read? No. Code like this just crawls off the right side of the page too easily, and in small, crowded listings, like a laser printer in landscape line printer font, you have a hard time telling which variable is being assigned to which expression. Have you spent much time looking through *LONG* assembler listings (I'm talking on the order of 1400 PAGES here) and trying to decide which comment goes with which line? -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
ray@micomvax.UUCP (Ray Dunn) (03/30/88)
In article <1136@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: >... > point[XX] = xp; > point[ZZ] = zp; > > /* z - axis */ > xp = point[XX]*cosyaw - point[YY]*sinyaw; > yp = point[XX]*sinyaw + point[YY]*cosyaw; > > point[XX] = xp; > point[YY] = yp; > >Easier to read no? No! To my eyes the divorcing of the lh & rh make it *much* harder to read. But for g*d's sake - why did you start another style war? Who cares what *you* find easier to read? Who cares what *I* find easier to read? Who cares what *(s)he* finds easier to read? Never the twain shall meet - guaranteed, and it doesn't matter! PLEASE DON'T POST YOUR OWN PERSONAL PREFERENCE OF THAT HUGE CODE SEGMENT! Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray
edw@IUS1.CS.CMU.EDU (Eddie Wyatt) (04/05/88)
> No! To my eyes the divorcing of the lh & rh make it *much* harder to read. > But for g*d's sake - why did you start another style war? newtoken[IATLOCAL].Aival = FALSE; newtoken[IATTYPE].Aival = ttype; newtoken[IATID].Aival = generate_tokenid(); newtoken[IATITIME].Aival = NULLINT; newtoken[IATMTIME].Aival = NULLINT; newtoken[IATCREATOR].Aival = NULLINT; Still having problems reading it? Rewrite the optional way and see if you still hold the same opinion. > Who cares what *you* find easier to read? > Who cares what *I* find easier to read? > Who cares what *(s)he* finds easier to read? I care on all counts! I care if the person that may end up maintaining my code finds it easier to read or not. Code format is an important issue. As an example, (I just love example - all of you out there should know that by now :-) the code segment: void add_3_by_3(m1,m2,a)register float *m1,*m2,*a;{register int size=9;if(a==m1)while(--size>=0)*a+++= *m2++;else if(a==m2)while(--size>=0)*a+++= *m1++;else while(--size>=0)*a++ = *m2+++*m1++;} is illegable. I know that this is an extreme but it does show that format counts. > Never the twain shall meet - guaranteed, and it doesn't matter! And therefore you also draw the conclusion that you should never try to understand the differences, particular to this case, why people might not like that format. The overall philosophy you seem to be applying here does not agree with me at all. I want to know PERIOD. Aside: generally the feedback I had gotten was unfavorable. However, I'm still apply the technique since *I* really think it helps. > PLEASE DON'T POST YOUR OWN PERSONAL PREFERENCE OF THAT HUGE CODE SEGMENT! You know where the 'n' key is don't you? Well use it. -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu