Over on inessential.com, [Brent Simmons discusses brace style in Objective C](http://inessential.com/2013/10/24/changed_my_mind_on_this_one_thing_with_b)
> I’ve always written my if statements like this:
> if (something)
> doAThing();
> That is — no braces when the code under the if is just one line.
> That’s never, not even once, been a problem for me. Never caused a bug.
In 25 years of coding in C dialects, I’ve never understood why people think that omitting the brackets improves readability. Coding is not, generally, improved by brevity or obscurity. The purpose is to write code that is clear in its intent, both to the compiler, the author, and future maintainers. If you know a thing about visual design, then you know that white space is your friend, so there is no need to skimp on that either.
#!objectivec
if (something) {
doAThing();
}
Always fully bracketed, always separate conditionals from statements and their accompanying braces. It makes it clear where the branch logic and actions reside and vastly improves readability and understanding. There is no source shorthand that somehow improves compiler optimisation, so you are really mostly writing for the benefit yourself and those who follow you.
#!objectivec
if (something) {
doAThing();
} else if (anotherThing) {
doAnotherThing();
} else {
doSomethingDifferent();
}
There are, of course, some exceptions to the rules, but I use reserve exceptions for those obviously exceptional circumstances. Sometimes you might have a long list of simple conditionals and simple actions which all need evaluating, in which case, it can occasionally add to readability to abbreviate.
#!objectivec
if (something) doAThing();
if (anotherThing) doAnotherThing();
if (somethingDifferent) doSomethingDifferent();
I know that is not equivalent to the previous code block, I’m just trying to illustrate a point.
The other exception to the rule is the ternary operator, which again, sometimes when used in simple situations can be more descriptive than the braced equivalent.
#!objectivec
something = condition ? onething() : orAnother();
The trick here is to ensure that the condition and true and false statements are simple – no compound statements or the use of bracketing to add confusion.
If you are worried about indentation levels, or page/function/method length, then you have bigger problems with your code than where to put your braces. We could argument that, if following the single responsibility principle, each method should be doing one thing (coordinating the flow of execution) and therefore the contents of braced blocks should only contain trivial statements or method calls to the place that really does the work. Sticking 20 lines of code within a conditional is probably a sign of excessive complexity and multiple responsibilities.
