asymmetric layout

SIEMON mls at whutt.UUCP
Fri Mar 18 00:28:30 AEST 1988


In article <1136 at PT.CS.CMU.EDU>, edw at 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 at 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)



More information about the Comp.lang.c mailing list