Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!umn-cs!ns!ddb From: ddb@ns.UUCP (David Dyer-Bennet) Newsgroups: comp.lang.c Subject: Re: Proposal for a scientific look at C style choices Message-ID: <1046@ns.UUCP> Date: 29 Dec 88 17:34:24 GMT References: Reply-To: ddb@ns.UUCP (David Dyer-Bennet) Organization: Terrabit Software Lines: 85 In article eric@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@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300