Braces are not Compiler-Fluff.

Daniel F. Fisher dff at Morgan.COM
Fri Jan 6 15:19:12 AEST 1989


In article <292 at ttwells.uucp> bill at twwells.uucp (T. William Wells) writes:
> 
> To summarize: there are (at least) two possible ways to indicate
> control relationships in a program, indentation and braces.  They are
> equivalent, in the sense that the braces can always be used to
> generate the proper indentation and the indentation can always be
> used to generate the proper braces.  Thus, the choice between them is
> between which conveys the information most readily.  Since
> indentation does so with little cost to the reader, but braces with a
> large cost, the choice is clear: use indentation to convey the
> information. Now, for understandability, braces have little use other
> than to convey this control information (the exception being that
> closing braces provide continuity of indentation, an argument for
> always using braces with multiple levels of indentation) this implies
> that braces should be used for their only essential function: telling
> the compiler what the control relationships are, and should otherwise
> be made as unobtrusive as possible.
> 
I three-quarters agree with him.  I am in complete agreement with
him on the role and importance of indentation (though he and I
probably indent different distances and with different white-space :-).
I do disagree regarding the role and importance of braces.  First,
yes, the closing brace should be used to signal a return to a lower
level of indentation.  But I think that this is less for the sake
of continuity and has more to do with how easy it is to spot a brace.
Thus since the left margin is already being scanned for indentation
clues to program structure, the left margin is the right place for
the closing brace.  Similarly, IMHO, the opening brace should not be
stashed away, but should clearly visible in the left hand margin.
This might not be true if were not for the fact that indentation is
often used to help make complicated control structures more
understandable.  Thus, I find "

    if ((p != (struct foo *)(0))
        && (p->barp != (struct bar *)(0))
        && (p->barp->type == BAR_BAZ_TYPE))
    {
        debazify(p->barp);
        saltpork(p);
    }

" more readable than "

    if ((p != (struct foo *)(0))
        && (p->barp != (struct bar *)(0))
        && (p->barp->type == BAR_BAZ_TYPE)) {
        debazify(p->barp);
        saltpork(p);
    }

                                                        ".
                                                         ^
                                                         |
And yes *ALWAYS* use braces!!                unobtrusive closing 
                                             period for all you 
                                             ex-COBOL programmers ;-)

> This, among style issues, is one of the few that is actually
> decidable on objective grounds. Arguing it, without reference to
> those objective grounds is pointless.
>
Right!!! 8^)

-- 
------------------------- MMM for HRE in '89 ------------------------
Daniel F. Fisher          Where do mooses get their trousers pressed?
dff at morgan.com            Maurice sez: "NO!"
------------------------- Are you an Elector? -----------------------



More information about the Comp.lang.c mailing list