>> I find the braces pure visual clutter in the latter. > What really bugs me is when my code winds up with a security fail because I $
Yeah, that bugs me too. But "don't be careless" isn't something codifiable enough to go on a list of style rules such as this one. > â??Because it looks betterâ?? is not a good reason to write less safe code. $ True as far as it goes. But, certainly for me and I suspect in general, "it looks better" correlates positively with being safe: the more transparent the transformation between the algorithm and the text, the fewer places for unpleasant surprises to hide. And, while there will of course be broad similarities, that level of transparency depends in part on the human in question, which is part of why we still have disagreements over style. Not that I haven't made similar mistakes. Anyone who hasn't hasn't written very much code. But rules cannot prevent anyone from making mistakes. The most they can do, the very most, is have a moderate effect on how likely various classes of mistakes are - and that takes us right back to dependence on the human involved. > My current coding style _requires_ braces for all dependent clauses, > even if there is only a single statement. I'd actually recommend one exception, that being the else-if chain: if the dependent clause after an else is a single statement, and it is an if statement, then, depending on the semantic relationship of the inner if's test to the enclosing if's, I can go either way on whether I'd prefer braces or no braces around the inner if. Slavishly always adding them makes it difficult to keep code from walking into the right margin: if (ch == t.c_cc[VINTR]) { ...do INTR processing... } else { if (ch == t.c_cc[VQUIT]) { ...do QUIT processing... } else { if (ch == t.c_cc[VKILL]) { ...do KILL processing... } else { ...etc } } } /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B