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


  • 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.

  • 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.

  • 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

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

Top White Papers and Webcasts

  • The open source cloud computing project OpenStack has come a long way since NASA and Rackspace launched it in 2010. Backed by leading technology infrastructure providers including Cisco, Dell, EMC, HP, IBM, Intel, and VMware, OpenStack underpins significant workloads at an increasingly diverse set of organizations, including BWM, CERN, Comcast, eBay, and Wal-Mart. For CIOs engaged in broader programs to win, serve, and retain customers -- and refocus business technology (BT) spend -- a planned and pragmatic …

  • Entire organizations suffer when their networks can't keep up and new opportunities are put on hold. Waiting on service providers isn't good business. In these examples, learn how to simplify network management so that your organization can better manage costs, adapt quickly to business demands, and seize market opportunities when they arise.

Most Popular Programming Stories

More for Developers

RSS Feeds

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