XCode: The Starting Curly Brace

UPDATE: With XCode 4 this process no longer works. There is a tool I found called Snippet Edit. It works really well and it is free.

As I dive deeper into the world of programming for Apple hardware I bring along with me past practices or habits that I must change in order to fit into the Objective-C world. It has been years since I last touched C/C++ and coming from a world of .NET and C#, my first impressions of XCode and Objective-C was basically taking a few steps backwards.

I couldn’t have been more wrong…

I see the power of what this new world has to offer and thus as I continue my journey I am finding myself taking new approaches to situations and even finding that some old habits I just flat out prefer to hold on to. Today, I’m talking about the placement of the starting curly brace.

Now, it seems to be common place in the C/C++ world where the starting curly brace is on the same line as the starting block of code. For example…

In the C# world it seems to be common place to place the curly brace on a new line. For example…

There are various arguments on why each one is better. Commonly I hear that the first method is better because it doesn’t have wasted space which results in less scrolling. While on the flip side, I commonly hear that by placing the curly brace on a newline it makes for easier readability. In the end, it really only comes down to personal preference as the placement has zero effect on the result of the executed code.

Personally, I prefer and have always preferred placing the curly brace on a new line. Why is this? Well, it is what I got used to while using Visual Studio for so long. It has occurred to me that the big named IDE’s out there seem to have a bit of a role, or rather influence, in how the community adopts the typical way a programming language is written out. With the exception, of course, of those individuals who take the time to rummage through the IDE’s preferences and change auto features to their liking.

Which is where my recent adventure comes into the story. While working in XCode I noticed the predicting text feature (amazing by the way, really wish Visual Studio had this) would always place the starting curly brace on the same line as my starting block of code. After a short period I stopped relying on the predicting text feature and just wrote everything out so that I would have to interrupt my typing flow to move the curly brace.

The image above shows XCode’s auto predicting magic (seriously, I have no clue what it is actually called) on an ‘if’ statement. Getting a little tired of having the starting curly brace on the same line I went through XCode’s preferences to change it but was given a little shock. There are no options to change this from the IDE.

I was a little disappointed but had not given up just yet as I did recall that the Apple world revolves around plist configuration files and held hope that maybe there was still a way.

Home: Library->Preferences->com.apple.Xcode.plist

I had found the plist file in the above location and as I opened it and looked through I couldn’t find any settings that would allow me to make the change I wanted. Looking around online I found what I was looking for, I needed the following inside this plist:

XCCodeSenseFormattingOptions as a dictionary along with BlockSeparator inside the newly created dictionary with the string value of a newline character.

I tried doing this manually through the plist editor that comes with the OS but I couldn’t get it to work correctly and so looking around online I found out how to manually edit plists from the terminal:

defaults write com.apple.Xcode XCCodeSenseFormattingOptions -dict BlockSeparator “\\n”

By typing in the above line I had achieved my goal:

Now when I type such statements as ‘if’ this is what automatically shows up in XCode.

The issues I had doing it manually through a plist editor was that I needed that hidden newline character ‘\n’ but typing it out manually only cause actual characters to be printed: For example…

if (condition)\n{



So, with that if any of you, like me, prefer to have their curly braces start on a newline in XCode. Just the bolded line above in a terminal and you should be all set. Happy Coding!

NOTE: If you copy and paste the bolded line be careful of the quotes. Might just want to type that part in by hand. It has been my past experiences that showed copying lines of code with single and double quotes from a website does not always go over too well everytime.

Author: Scyanide

Software Engineer wanting to share his experiences.

21 thoughts on “XCode: The Starting Curly Brace”

  1. Funny, I like my C# with type 1 braces.

    Those quotes are quite curly. WordPress is likely doing that because curly quotes look better — except in this case the quote are functional, not stylistic. You may be able to disable that feature (or selectively for code blocks).

  2. AH! Than you! Just what i was looking for!

    (Although it was annoying that I had to register to thank you :P)

    1. Yeah, sorry about that Softnux. I thought of only allowing registered users comment to help ease up on possible spam. I may change this though.

      Glad I could help you out!

  3. I too had problems with the quotes.

    I was able to completely remove them from the command line and it worked just fine:

    defaults write com.apple.Xcode XCCodeSenseFormattingOptions -dict BlockSeparator \\n

    Thanks for this tip!

    “Opening curly braces belong on a new line” proponents of the world UNITE!

  4. I prefer the brace at the end, but now it doesn’t matter. GNU indent automatically adjusts the placement of brackets. It *might* work on C#, too. I wrote a simple preprocessor to automatically add missing brackets, semicolons and parenthesis. It works so well that I just crank out pseudocode and it bangs it into shape, ignoring lines that end in comments or white space. It *should* also work with C# if you want to test it out, fix bugs. http://freshmeat.net/projects/anchor

  5. Funny that the morons continue to desire so strongly doing things the stupid way rather than the K&R way
    good thing all source formatters and sensible defaults use K&R style so coders with IQs higher than 100 can unfuck the code created by the morons who waste space with braces on their own lines!!!

    1. This “wasted space” has 0 impact on the code being executed. Putting the curly brace on a new line helps block off the code inside and improves readability. I highly doubt a person’s IQ level has anything to do with where they place the curly brace.

      It all comes down to preference, however. Feel free to place it anywhere you want. Unless you work for a company that has standards on the format, in which case you have to do as they say. My experience has shown than many companies enforce newline curly braces for readability.

  6. Very nice!
    I hadn’t quite decided which I prefer, but was aware that there were very much two camps on this. On further reflection, I’ve decided that your readability argument is the winner for me.
    Thank you!

    1. I was hoping it would still work for 4.3 but I’ll look into it when I get a chance and put a update on this post. I have noticed that it no longer puts the curly brace on the newline for me but figured the setting was reset and I’ve been too lazy to fix it.

    2. I found this searching around:

      Seems XCode 4 changed a few things up and relies heavily on its built-in snippets for auto-completion. The marked answer goes into how to find and edit SystemCodeSnippets.codesnippets file. It has to be done manually at the moment.

      Also, looks like this guy is giving out the modified file for people.

      Hope this helps. Thanks for pointing this out to me. I’ll update this page to accommodate the changes in XCode 4.

  7. Being very old programmer from the late 70’s (when I was very, very young) the argument I remember for putting the curly brace on following the statement had to do with publishing costs. Back in the old days, the source code was printed in the back of the books and this simple change saved pages of expensive printing. At the cost of maintenance of actual source. Since so many books took advantage of this space saving technique, scores of software engineers, programmers and hackers just followed along what they learned through example. Those that have programmed from a long time value the ease and consistency of the paper wasting technique to line up the block statements and avoid unnecessary confusion and the visible advantage of obvious block organization. At least that’s how I remember it happening – as it has annoyed me for three plus decades. Being forced into a format inspired by non-programmers by any IDE… really, really bugs me.

    1. That’s interesting. I think I’ve heard of it being that way before but it never crossed my mind. I’m very picky with my alignments and feel that the curly brace on a newline helps with block readability and organization. I’m also not a big fan of embedding statements into 1 line. Prefer to separate it all for readability AND for debugging purposes. Luckily for us, it doesn’t have much, if any, impact during runtime.

  8. I had been encouraged this site through this relation. I am not positive no matter if this specific placed is written as a result of him or her because no one comprehend such given around my personal problems. You might be remarkable! Many thanks!

Leave a Reply