Proposal for a scientific look at C style choices

[David Dyer-Bennet]

In article <eWl9H#2cdgbS=eric at snark.UUCP> eric at snark.UUCP (Eric S. Raymond) writes:
:switch (val)  /* comb style */           switch (val) /* block-indented */
:{                                        {
:case VAL1:                                       case VAL1:
:        /* stuff */                                      /* stuff */
:        break;                                           break;
:}                                        }
:
Actually, the problem *I* have with comb style, other than unfamiliarity,
is that I can't find the end of the switch body by scanning for the next
character at the level of the switch.  (I find scanninng for ANY character
a much faster operation than scanning for a "}" specifically).  Your block
indented style also has this problem -- I get hung up on the openning brace.
Which is why I do K&R style brace placement.  My personal weirdness here
is to move the indentation of the "break" back OUT to be directly under the
"case"; essentially treating it as a closing delimiter.  Once again this
is motivated by wanting to find the end of the current block by scanning
down for the first thing directly under the start of the current block.
Thus we get:

switch (val) {			/* dd-b style */
    case VAL1:
	/* stuff */
    break;			/* case VAL1 */
    ...
}				/* switch val */

:but that
:
:switch (val)
:    {
:case VAL1:
:        /* 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'.

This violates a VERY low-level rule, namely that things should never be
indented less than the level they started at.  Once you indent that first
brace, you can't place anything to the left of it until you hit the closing
brace.  That seems to be true in all major programming styles.  It's certainly
basic to mine (as mentioned above, I want to scan down for the first character
under the block start to find the block end).

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

I value conservation of vertical space highly, but I don't have the
rule about braces you propose.  I tend to agree with the poster who
said that braces are necessary only because the compiler isn't smart
enough to interpret block structure from the indentation.  Has anybody
played with such a compiler, by the way?  Or a checker for C which
would complain if the actual block structure didn't match that implied
by indentation?

: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).

Either to the guard part, or else I regard them as a separate entity.
This, of course, is contrary to the language definition, but it makes
for more readable code.  (No, this isn't the style I first learned in
a structured language.  This is about my third stylistic obsession.)

I think of 
    if (cond) {
	/* stuff */
    }
as one statement, so I like having it begin and end at the same indent
level.  Also, if there happens to be white space or an end of page
after the closing brace, having that brace at "if" level is the only
way to put something at that level to stop my eye before it scans on down.

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