Proposal for a scientific look at C style choices

David Dyer-Bennet ddb at ns.UUCP
Sat Jan 14 08:41:14 AEST 1989


In article <11091 at ulysses.homer.nj.att.com> ggs at ulysses.homer.nj.att.com (Griff Smith) writes:
:I'm using this as an excuse to suggest a theory: two kinds of people
:are arguing, and they have different perceptual strengths.  
:
:David Dyer-Bennet seems to be a member of the `parsing' school.  These
:people like to `read' code instead of `seeing' it.  I won't explain
:their perceptions, because I can't empathise with them.  

I think this analysis is right -- except I think I'm in the visual camp;
I'm the one who was explaining my use of whitespace and placement in
terms of page design, and in terms of finding things visually.

:They make life miserable for me, however.

Er, sorry about that.

:When they format similar code, it's something like
:
:if (whatever && something_else &&
:	something_on_the_next_line &&
:	something_short && something_longer &&
:	the_end_of_the_list) {
:	mumble;
:}

In my case, this would be:

if (whatever && something_else &&
  something on the next line &&
  and_so_forth_on_and_on_until &&
  the_end_of_the_list) {
    the_body;
    of_the;
    compound_statement;
}

And I consider this suboptimally readable.  I don't encounter long continued
booleans in the if that often.  If I did, I might revise my style at least
for those particular statements, because I agree with you that there's some
difficulty separating the conditional from the body in the above.  Do you
have trouble with the simpler case of

if (simple one-line conditional) {
    body_of;
    compound_statement;
}

?  Essentially, I tend to think of "continuation lines" (like the long
conditional in your example) as exception cases, rather than the norm,
so my style handles them less cleanly than what I think of as the common
cases.

:This style maximizes my confusion by forcing me to `find' all the
:component markers instead of `seeing' them.  I have lost most of the
:visual cues, and I have to go wading through the code with my defective
:parser.  I suspect the `parsers' are equally disturbed by having to
:discard my superfluous white-space.

As I format it, the indentation depth provides the visual cue still.
I hope.  I don't parse code well either.  This is easily determined by
presenting me with code formatted in ways contrary to the actual
meaning, and see how long it takes me to find it!

:I don't have any solutions.  I do wish the two sides would be more
:sympathetic to each other's problems.

I'm learning a lot from this dialogue, and I'm really pleased it IS a
dialogue rather than a shouting match.  As you say, we aren't likely to
all come to a common solution, but building understanding of the problem
is valuable.

-- 
	-- 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



More information about the Comp.lang.c mailing list