Proposal for a scientific look at C style choices

[David Dyer-Bennet]

In article <135 at mole-end.UUCP> mat at mole-end.UUCP (Mark A Terribile) writes:
:In article <1045 at ns.UUCP>, ddb at ns.UUCP (David Dyer-Bennet) writes:
:> :Likewise, I generally write
:> :
:> :	if(    a->op == XNES_step
:> :	    && a->size <= XNES_bufsize
:> :	 ||    a->op == XNES_fix
:> :	    && a->size + a->leftover <= XNES_bufsize )
:> :	{
:> :		. . .
:> 
:> However, your strange idea violates one of MY basic concepts of code
:> formatting: indentation is something that takes place between the left
:> margin and the first character on the line, NOWHERE ELSE.
:
:Hmm.  Do you mean that you have never written
:
:#if ...
:
:#  if ...
:. . .
:#  else
:. . .
:#endif

Well, I understand dpANS allows the "#" to be the first non-blank character
on the line, rather than precisely the first, so this could be done in the
normal obvious way in a compliant compiler.  I believe that that's what I've
done when I nest conditionals (not too often, obviously).

:My criterion is communication: how well does the typographical layout of the
:code on the page communicate the organization of the code? 

Yes, of course.  Obviously you are another Reasonable Person :-).  I think
most of us agree with this.  The problem is, page design is an art not
a science, and essentially none of us are trained in it.  We're going to
come up with different ideas of what communicates the organization best.

:Does the example first given carry the principle too far?  Having waded
:through thousands of lines of code whose lines were broken where nroff would
:break them and whose authors evidently thought more levels of parentheses
:were better ways of communicating to the reader than typography, I think that
:the principle is NOT carried to far, if only because it serves to inspire
:people working with me to improve a little.  As it might have been written:
:
:	if(((a->op==XNES_step)&&(a->size<= XNES_bufsize))||((a->op==XNES_fix
:		)&&((a->size+a->leftover)<=XNES_bufsize)))

There is another option besides your first example, and this example of how
not to do it:  Pick the line breaks for clarity, follow a consistent indenting
rule for each line.  This can be done with indentation strictly at the left.

(Thinking back, I can remember having used a format with internal whitespace
for an algorithm with clear "two-column" format, but this example does not
appear to me to have that.  If nothing else, it's too short.)

Try this:

    if (((a->op == XNES_step) && (a->size <= XNES_bufsize)) ||
      ((a->op == XNES_fix) && ((a->size + a->leftover) <= XNES_bufsize))) {
	/* code */
    }

(half-unit indent indicating a continuation line)

For a more complex expression I would tend to indent blocks as indicated
by the parenthasization of the expression.

:(Ok, even nroff wouldn't have put the ``)'' at the beginning of a line.  I
:have seen it done by programmers, however.)

Ucky poo.  Blecch.

-- 
	-- David Dyer-Bennet
	...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
	ddb at Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
	Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300