Pedantic Coder : Where do braces go?


I’ve become rather pedantic about my coding style over the years.  I’ve worked in a number of people’s code, and have always felt most comfortable in the core NT code because of the consistency of formatting, naming, etc…  This is a coding style that we often call "Cutler Normal Form" in deference to Dave Cutler.

Despite this I recently made a change in the way I place my braces around blocks of code.  CNF says that braces go at the end of the line that will execute the code block, as follows:

if (foo) {
    do something;
} else {
    do something else;
}

I used to really like this style.  It made it clear to me when the statement being evaluated was continued into the next block.  Of course I always use braces, even when I only want one statement in the if or else clause, so this was a quick way to look and be sure i’d set things up correctly.

I’ve now transitioned over to:

if (foo) 
{
    do something;
} 
else
{
    do something else;
}

This was the preferred style of the folks in the UMDF group when I joined the project.  It took me a while to warm up to this.  However i eventually found two things that i like about it.

First it leaves more open white space.  In my "old age" (i.e. mid thirties) i find that i like more whitespace in my code.  It improves the readability for me, and makes me work harder to keep my functions fitting on a single page – which is a good threshold for whether they’re understandable or not.

The second is that it makes it much, much easier to put part of the block under an IFDEF.  This to me was the winner.  Now i can do:

#if bar
if (foo)
{
    do something specific to bar;
}
else
#endif
{
    do something else;
}

Rather than:

#if bar
if (foo) {
    do something specific to bar;
} else // note that there would otherwise be a { here
#endif
{
    do something else;
}

Or even worse:

#if bar
if (foo) {
    do something specific to bar;
} else {
#else
{
#endif
    do something else;
}

Perhaps it’s a silly thing to change something as fundamental(ist) as brace formatting style to get around a little inconsistency in how you preprocess out part of a conditional.  But i like consistency … the hairs on the back of my neck go up when i see code that’s not in my normal format.  So in the end this made me more comfortable.

This has come up quite a bit for me when debugging something or refactoring something.  When refactoring i’ll frequently #if out a chunk of impacted non-critical functionality (usually replaced with a failure case) until i’m ready to deal with that chunk of code.  For debugging it can be useful to do the same thing if you’re trying to track down the cause of a crash and are at your witts end.

And I’ve come to find it prettier.

-p

Comments (8)

  1. Zooba says:

    I’ve always preferred the more expanded version, though in very simple cases I’ll write one-liners:

    if(value > 100) value = 100;

    I consider that better than the four-liner (including braces) and it clearly shows that only one instruction will occur.

    I’m still waiting on a mainstream app/plugin that transparently formats code according to the user (maybe at the checkout point?). Having code formatted as you like to see it has a massive impact on how easy it is to read and modify.

  2. Plugh says:

    I’d also been a CNF patriot … until I moved over and spent a while in C# and now I’m a fan of the new way, that is, the way you describe.

    if (bar)

    {

       foo();

    }

    else

    {

       dang();

    }

    There’s a couple of other CNF things I’m a fan of, such as, braces always.  That is, it doesn’t matter if it’s a single line body or multi line, you always use braces, never ever

    if (bar)

       foo();

    else

       dang();

    I’ve been playing in open source for a while now and it takes me back to my old unix days but, those with coding styles in the current open source (linux) world seem to be very heavy proponents of NOT using braces for single line bodies.  (I haven’t actually gone and read the linux kernel programming style guidelines but they do exist).  Certainly in the last couple of days as I’ve been heavily adding print statements (for debugging) to some code it would have been easier to just add the print rather than the print AND the braces as I try to work out where the heck this code is going.  So, I’ll remain a proponent of braces everywhere.

    Another CNF’ism that I quite like is not to assume a boolean result (actually prohibited in C#).  That is, use

    if (foo == NULL)

    {

       return ERROR_SOMETHING_BAD;

    }

    rather than

    if (!foo)

    {

       return ERROR_SOMETHING_CONFUSING;

    }

    Of course Dave is also a fan of always comparing to zero so you find a lot of

    if (foo != FALSE)

    which I found hard to read for a long time.  But, the code produced for that is always likely to be better than for

    if (foo == TRUE)

    You’ll never get me to produce my locals in alphabetical order though 🙂

    Say hi to the little un for me.

    -P (the other)

  3. Peter's a topic stealing stealer person. So rather than pout about how he's stolen my thunder

  4. sidinsd says:

    I am a bit older than you, in my 50’s and have been coding for over 30 years. I used to think that the difference in bracing styles was a generational thing, i.e the old guys, like me, liked the more expanded style, while the young Turks liked the more compact style. It is nice to see some of you younger guys agreeing with us dinosaurs.

  5. thingfish47 says:

    As a coder in his 60’s I concur with sidnsd and the general theme.  There ia a little program called astyle that does reformat code for you.

    http://sourceforge.net/projects/astyle/

    Enjoy!

    btw

  6. thingfish47 says:

    btw

       value = max (value, 100);     // neat and concise

  7. Tim says:

    Agree with this formating style, but with "else" I put it on the same line as the closing }.

    "I'll remain a proponent of braces everywhere."  Same here.