SUMMARY: Brace style -- why should I care? 
Author Message
 SUMMARY: Brace style -- why should I care?

In a recent posting to comp.lang.c.moderated I offered to make
a survey on the subject of "Brace Style". I asked everyone to
email me whether anybody ever had problems with other people's
brace or white space styles:

>  Let's make a survey: everyone who ever took 'if()' as a function
>  e-mail me when and why. [Everybody who never did please do so, too]

I got email replies from seven persons (in random order):

The quantified results read roughly

        6.5 : 0.5

in favour of "No problems with braces and if() vs if ( )"

If I had to put it in a nutshell I'd suggest:

 "If you feel comfortable with only the brace style you are used to
  and have to work on someone else's code, use indent(1) to format
  it to your taste (and reformat it to your project's style when done).
  Decent editors will also help a great deal in understanding brace
  grouping. Use brace-matching functions like % in vi or turn on
  syntax coloring.
  However, all these suggestions are moot for printed code."


SIGSIG -- signature too long (core dumped)

Disclaimer: the following replies have been edited beyond recognition.

  What REALLY makes code readable is a color sensitive editor.
  If you don't have a color editor, get one.


:   Why should I ever care what brace style me or anyone else is using?

    You should only care if you gain empirical experience that a
    particular style causes errors to be more difficult to find by
    simply scanning some code than by another method.
    For instance, I typically use:
    if(foo) {
    } else {

I use vi on UNIX && BBEdit on a Macintosh, and can bounce on the braces
in either to make sure everything is in balance. Otherwise, I might
have developed a different style.
For instance, in a language I use called AML for GIS applications,
directives (a form of keywords) are preceded by '&' so a block looks
like this (variables are enclosed w/o spaces in '%'s):
&if %some_variable% &then
        statement N

Since I don't know of any editor that will 'bounce' on the
&do/&ends, I set them off so that I can visually scan down the code
to see where the mates are. After much experience, I have found that
&if %a_var% &the &do
is patently difficult to keep track of, particularly when there are
many nested &do/&end blocks.    

But, if someone used a different style && I couldn't discern the
meaning of their code, I'd (as you say) look for other work.

: Unbelievable what traffic these 'brace style' threads produce.

When I first started to learn to write C (it's my 1st programming
language), I read these style threads for an understanding of
what the hoopla was about. It helped me develop a consistent
style that I can write in without thinking much about it.
It does have it's place.


>  Why should I ever care what brace style me or anyone else is using?

Bob Stout gave some excellent advice when this topic arose in a
different forumn. If you're working on someone else's code or in a
project environment, get yourself a copy of CClearly or the

Convert any source to your personal style when you check it out, and
back to the group style when you check it back in. Then you really
DON'T have to worry about style.



> [snip lots of very astute commentary]

>  Let's make a survey: everyone who ever took 'if()' as a function
>  e-mail me when and why. [Everybody who never did please do so, too]

>  In a similar spirit, everybody who uses

>      if (cond) {
>            ...
>      } else {
>            ...
>      }

>  and is confused to the max upon reading

>      if(cond)
>      {
>            ...
>      }
>      else
>      {
>            ...
>      }

>  (or vice versa) please email me when and why. I will summarize.

Well, I did just have an occurrence like that.  Someone wrote some code that
went like this:


and made me debug it.  I happened to read from bottom up, and was quite
confused as to why he had an empty while() statement.

Maybe this is a commentary on my own code-reading style (or lack thereof) than
on anyone's brace style. :-)



>Unbelievable what traffic these 'brace style' threads produce.
>Aren't there better issues to talk about? Dear mod: How about
>excluding brace style from the list of on-topic issues? What
>about pointing inquiring minds to the unmoderated c.l.c?

The brace style thread introduced me to ideas that I hadn't thought of
before. It also made me think about, "How should I decide on a good style
for my own code, instead of just blindly using the one that I have
'evolved' over time?" And it provided a reference to a fairly good (though
expensive) book: "C Style: Standards and Guidelines" by David Straker.

I have no objection of the moderator stops the thread (including this
message), but it was worthwhile for at least some people.


I _never_ thought, if for or while where functions ... (really! ;-)

I prefer:





> Let me illustrate my point by quoting a recent article:
> [this is about white space style actually, but I hope you get the point]

> >For if's, and such, I would hesitantly point out that these aren't
> >functions, and shouldn't be written as though they were functions.
> >Writing ``if ( ... )'' and ``sin( ... )'' helps achieve that.

>   Oh boy. If anyone could be confused by that, s/he better look
>   for another job.
>   Let's make a survey: everyone who ever took 'if()' as a function
>   e-mail me when and why. [Everybody who never did please do so, too]

I never had that particular problem.

The problem is, you have to figure out what stuff goes with what other stuff.
You can have multiple nested if's, while's, and what have you; you can have 50+
lines of code between the condition and the "else" that goes with it!

Brace style matters, but only because it goes hand in hand with whitespace
style, especially indentation. It all depends upon the particular code
construct you are trying to make.  If you get into the *habit* of doing it
correctly you aren't using up any extra time, and you're doing a great service
to the next guy or gal who has to read your code.

In my intruductory programming class (using Pascal -- dating myself :) the
instructors ran our source code against a program that replaced all
non-whitespace with random characters -- we were docked points if the
instructors couldn't figure out what was going on from the results.

>   In a similar spirit, everybody who uses

>           if (cond) {
>                 ...
>           } else {
>                 ...
>           }

A must for "awk" scripts

>   and is confused to the max upon reading

>           if(cond)
>           {
>                 ...
>           }
>           else
>           {
>                 ...
>           }

>   (or vice versa) please email me when and why. I will summarize.

I certainly hope no-one replies in the affirmative, but see above.

Hell, if it's a simple if statement that only does one thing, you can
put it all on one line! :-)

I'm always switching back and forth between C, Pascal, C++, Basic, and various
UNIX scripting languages, using Pascal mostly.  I freely admit to the dirty
habit of making a "#define then" macro so that my Pascal indentation style
works in C and C++.  OTOH I _don't_ put parentheses around "if" and "while"
conditions unless I'm writing in C or C++!


Sat, 08 May 1999 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Brace Style? Why should I care?

2. C Brace Style

3. one true brace style

4. 'One True Brace Style'

5. Bracing style (was Re: Teacher mistake on code ???)

6. why no braces for single statement blocks?


8. re : why no braces for single statement blocks?

9. Programming style with arrays, summary

10. Indian Hill style guide - summary

11. Why uninitialized memory? [Summary (long)]

12. summary: why do we need == and != ?


Powered by phpBB® Forum Software