Over a million developers have joined DZone.

A Collection of Objective-C Style Guides

DZone's Guide to

A Collection of Objective-C Style Guides

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

Ah, the great thing about standards is there’s so many to choose from. And here’s a new style standard for all us Objective-C programmers, from everybody’s favourite tutorial centre:

…the team and I are very pleased to announce the official raywenderlich.com Objective-C style guide!

This style guide is different from other Objective-C style guides you may see, because the focus is centered on readability for print and the web. Many of the decisions were made with an eye toward conserving space for print, easy legibility, and tutorial writing…

Pretty conventional most of it; the most interesting is this bit, which after due consideration we’ve decided has successfully convinced us that private properties add enough flexibility to be worth the smidgen of extra complexity:

The part of the guide that was the most controversial by far was the answer to this question: Should you prefer private instance variables, or private properties?

Main argument for preferring private instance variables: Do the simplest possible thing that works (and prefer saving space). Why add the overhead/complexity of private properties if you don’t need them?

Main argument for preferring private properties: Properties bring a lot of Objective-C goodness such as key-value coding, future proofness, a little more consistent overall.

Both approaches are completely valid ways of doing things, and both sides had valid points. However, we felt we should choose one for consistency’s sake.

After a heated 118-comment discussion, StackOverflow discussion, and very close vote, private properties won the day – at least for now :]

[EDIT: Worried about overhead? Check out Should I Use a Property or an Instance Variable? Spoiler: Property.]

And if you get down to the end there’s a list of other style guides, including a few that are new to us:

Personally, rather than set out a style guide as such, we loosely follow these principles:

  1. Clarity. There’s always at least two programmers on a project — you, and you coming back to fix bugs sometime down the road once you’ve completely forgotten what on earth you were thinking when you wrote this junk. Make it easy for the second programmer to understand looking at a single screenful what’s going on at any given line assuming no known/remembered context whatsoever.
  2. Malleability. Separate conditions and consequences; separate not necessarily connected actions; restrict scope to practical minimum. Easier it is to manipulate the code, the fewer bugs you’ll have and the quicker they’ll get fixed. This is why Allman style is The One And Only Correct Bracket Methodology: see the conditional compilation example at the end of that link’s section for the definitive demonstration of why.
  3. Terseness. Given two semantically identical structures, pick the shorter form. Note that this puts us at odds with common practice in the case of dot-notation syntax, as expressed in the raywenderlich.com style guide (cribbed from the NYT’s, apparently): “Dot-notation should always be used for accessing and mutating properties, as it makes code more concise. Bracket notation is preferred in all other instances…” Uh, why? Property-related calls are functions, “all other instances” are functions too. What is the magical unstated difference here that somehow makes concise only a virtue for functions that (conceptually) wrap value storage, and not for all functions? Not seeing any, dude. Use UIApplication.sharedApplication.delegate, or UIColor.whiteColor? Well, why not?
  4. Verifiability. Always write code in a fashion that allows the strictest compile time checks possible. So you should never use “id” for anything with a modern compiler. Use “instancetype”, or a protocol consisting of all calls potentially made to that object. Likewise, use NS_ENUM for enumerations.
  5. Mothership Consistency. If you can’t form a clear argument based on the first four points, go with the style used by the majority of Apple’s SDK headers and/or recent sample code. Most commonly resorted to in the case of holy wars over whether there’s a space in (NSString *)argument or whether it should be a spaceless (NSString*)argument and similar near totally pointless quibbles.

For the most part the raywenderlich.com style guide is perfectly compatible with these principles, the quoted artificial restriction without any justification given on use of dot notation is the only thing that jumps out at us as pointlessly silly. And we’d quibble with the K&R brace style, but wanting to save a line is defensible targeting print instead of our 27+” monitors, so we’re ok with that given the purpose. As opposed to all these other ones in the list, which all advocate K&R it appears; they’re just indefensibly wrong there, which is much worse than defensibly wrong. And none of them save Github’s are even somewhat close to our “everywhere, why not?” stance on dot notation. Hmmm, maybe we will get around to writing a Trollwerks Style Guide, sometime this millennium we run short of fundamentally meaningless things to argue about. But it won’t be soon.


An Xcode Plugin Enabling Easy Use Of The Clang Source Code Formatting Tool

Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}