Proposal for a scientific look at C style choices

[Eric S. Raymond]

The recent (remarkably civil) discussion oF C layout styles has piqued my
curiosity. I want to ask comp.lang.c's help in taking a real, analytical look
at the quesion of why people lay out C code the way they do.

C code layout is a classic example of rule-governed behavior in which the rules
are inexplicit and often less than half-conscious, but evidently very strong.

What I'd like to do is work out something like a decision tree or graph that
has coders' value choices about various aesthetic issues as arcs and various
described coding styles or coding style classes as nodes -- a sort of
functional taxonomy of coding styles.

To illustrate the approach I have in mind, consider the distinction between
"comb-style" and "block-indented" switch layouts:

switch (val)  /* comb style */           switch (val) /* block-indented */
{                                        {
case VAL1:                                       case VAL1:
        /* stuff */                                      /* stuff */
        break;                                           break;
case VAL2:                                       case VAL2:
        /* more stuff */                                 /* more stuff */
        break;                                           break;
default:                                         default:
        /* yet more stuff */                             /* yet more stuff */
        break;                                           break;
}                                        }

(The reader may prefer a different indent depth, or may not put the opening
bracket on its own line. In this context, these are details)

Now, I *think* that the "comb" versus "block" choice hangs on a question
that goes something like this:

Question S: are you willing to make an exception to the global rule that the
contents of a control block is indented one level deeper than the "sentinel"
part in order to make switches look more like jump tables, or to reduce their
cost in visual nesting depth?

If I'm right, this is one node in the ur-graph of C styles I'm after. The
interesting question: are there other, *fundamentally different* criteria on
which this choice can be made? If so, what are they? 

Consider, also, that in one major style (Whitesmiths) it is natural to write:

switch (val)
    {
    case VAL1:
            /* stuff */
            break;
    case VAL2:
            /* more stuff */
            break;
    default:
            /* yet more stuff */
            break;
    }

but that

switch (val)
    {
case VAL1:
        /* stuff */
        break;
case VAL2:
        /* more stuff */
        break;
default:
        /* yet more stuff */
        break;
    }

appears to be quite rare and strikes most C programmers as unnatural, even
though it's the logical combination of "comb" and Whitesmiths style. What
rules are operating here? I can guess, but then I *know* what my rules are;
I'm curious about other peoples'.

Let's start by mapping a really major node. Maybe the most basic question
in C layout is:

Question A: Which do you value more; conservation of vertical space, or a
global rule that start braces go at the same visual indent level as their end
braces?

If your answer is "value conservation more", then you are likely to use
Kernighan & Ritchie style:

if (cond) {
     /* stuff */
}

If you value visual symmetry more, then you are likely to use one of the
other two major style classes:

if (cond)    /* Whitesmiths style */
        {
        /* stuff */
        }

or

if (cond)     /* BSD or "Neo-Pascal-oid" style */
{
       /* stuff */
}

I think the tension between these is captured by:

Question B: in control structures, do you consider the braces to be more
firmly glued to a) the "guard" part, or b) the enclosed statement(s).

If your answer to "B" is a), you're likely to plump for the Pascal-oid layout.
If it's b), you probably like some Whitesmiths variant. I *think*. I'm inviting
comment on all this.

This is a kind of investigation the net ought to be perfectly suited to. At
the very least, maybe we could develop a useful standard terminology for
the major layout styles. (For example, I'm very sure the Berkeley crew used
more than one layout style; I'd like a better term for what I've called "BSD"
layout, particularly since it's what I happen to use).

Once we've mapped the "style graph" we can use the net to make something like a
scientific survey of usage frequencies, correlations with various "programming
cultures", etc. Real knowledge could come out of this!

Criticisms and suggestions for improvement of my terminology, my proposed
A, B and S nodes, and anything else I've raised here are welcome. Well-thought
out descriptions of other key decision points wouuld be even more welcome.
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      Email: eric at snark.uu.net                       CompuServe: [72037,2306]
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718