Where Most Developers Put their Braces

When creating blocs, where do you put the squiggly braces in your code? It isn’t a question with an answer that will cause programs to run faster or developers to be more efficient, but it is a question that can cause a huge amount of debate among developers. Where do you put your braces when you are creating blocks of code? With over 1200 responses, we now have the winning answer!

There are generally three styles that come up when people where to put braces. The first style is to put them on their own line:

Braces Belong on Their Own Line

The first of four options we gave in asking where brace go is to put them on their own lines:

A Block
{
    // Stuff
}

Braces Belong ont eh Same Line as the Rest of Code

The second style puts the opening and closing braces on the same line as other code:

A Block {     /* Stuff */ }

The Opening Brace Should be with Other Code. Closing Brace Should be on Own Line

And, the third style puts them all on the same line

A Block {  
    // Stuff  
}

No Need for Braces

Of course, we also tossed out the option in our survey for people to say they don’t use braces.

The Results of Brace Usage

The end results are shown in the following graph. With over half the votes, most developers believe braces belong on their own lines. Second with nearly a third of the votes was to put the opening brace on the opening line of code, but keep the closing brace on its own line.

Where Most Developers Put their Braces

Of course, if you split out the votes from those that took the poll on Codeguru from those that were on VBForums, the results change a slight bit. The order stays the same; however, on Codeguru the winning area goes up to 61% whereas on VBForums, it drops a little to 50%.

Did the winning style of using them on their own lines match what you do?



Blog Categories

Blog Archives

Comments

  • Mr.

    Posted by George Fullen on 01/21/2016 10:08am

    The 3rd option (opening brace with other code, closing on it's own line) is what I use. Thus, a line of code ends with either a semicolon or brace. Thus it ends with something. Also, this visually links the block with the triggering line. Just a personal preference.

    Reply
  • It depends, but never the third style

    Posted by Rubidium on 06/19/2014 10:03am

    For me it depends: I prefer compactness when possible, so I usually let them on their own lines, but for very simple properties and for one-instructions-methods I tend to write everything together on the same line. Having short properties and methods on the same line allows for fast identification of their contents without need to expand the code: if the code is collapsed, then it does something not so simple, or some comments have been added. I never use the third style because it reduces recognition of code flow branching at glance.

    Reply
  • re braces

    Posted by will on 06/01/2014 03:53pm

    no one commenting on these articles ? well after wresting what looks better many times i came to the conclusion that either is ok but i tend to have a unofficial pathology to that one liners remove the brackets simple if's with code bracket on the same if line code follows end bracket separate line same for if else if they are pretty simple and other if else dont border or lie within them ... if they do... i tend to put the brackets on a separate line for clarity

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • On-demand Event Event Date: March 23, 2017 As you adopt the use of cloud services, whether in public/IaaS, SaaS or hybrid environments, the attack surface expands and, if breached, the costs increase exponentially. This session is designed to help IT and security leaders understand and address the unique challenges that enterprises typically face when they deploy their applications in the public cloud. It summarizes the areas that the public cloud vendors typically take care of and highlights the areas …

  • On-demand EventEvent Date: March 21, 2017 With the rise in ransomware attacks, bank heists that reached new levels of sophistication, and extortion plots that were beyond anything we could have imagined, 2016 certainly was an eventful year for cybersecurity. Going into 2017, no business can afford to be uninformed about cybersecurity or unprepared for an attack. Watch this informative webinar, presented by Andrey Pozhogin, Senior B2B Product Marketing Manager at Kaspersky Lab, as he examines predictions for …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date