We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.

Even though Objective-C tends to be a more verbose language than C++, to aid in the interoperability with that guide, we have decided to keep the limit at 80 columns as well. It's easier to live with than you might expect.

We recognize that this rule is controversial, but so much existing code already adheres to it, and we feel that consistency is important.

You can make violations easier to spot in Xcode by going to Xcode > Preferences > Text Editing > Show page guide.

Methods should look like this:

The spacing before the asterisk is optional. When adding new code, be consistent with the surrounding file's style.

If you have too many parameters to fit on one line, giving each its own line is preferred. If multiple lines are used, align each using the : before the parameter.

This is similar to public, private, and protected in C++.

If you must use Obj-C exceptions (please see Exceptions for reasons why you should not be using exceptions) format them as follows:

File extensions should be as follows:

File names for categories should include the name of the class being extended, e.g. GTMNSString+Utils.h or GTMNSTextView+Autocomplete.h

In order to minimize clashes between the differing naming styles when mixing Cocoa/Objective-C and C++, follow the style of the method being implemented. If you're in an @implementation block, use the Objective-C naming rules. If you're implementing a method for a C++ class, use the C++ naming rules.

In application-level code, prefixes on class names should generally be avoided. Having every single class with same prefix impairs readability for no benefit. When designing code to be shared across multiple applications, prefixes are acceptable and recommended (e.g. GTMSendMessage).

For example, if we want to create a category on NSString for parsing, we would put the category in a file named GTMNSString+Parsing.h, and the category itself would be named GTMStringParsingAdditions (yes, we know the file name and the category name do not match, but this file could have many separate categories related to parsing). Methods in that category should share the prefix (gtm_myCategoryMethodOnAString:) in order to prevent collisions in Objective-C which only has a single namespace. If the code isn't meant to be shared and/or doesn't run in a different address-space, the method naming isn't quite as important.

The method name should read like a sentence if possible, meaning you should choose parameter names that flow with the method name. (e.g. convertPoint:fromRect: or replaceCharactersInRange:withString:). See Apple's Guide to Naming Methods for more details.

Accessor methods should be named the same as the variable they're "getting", but they should not be prefixed with the word "get". For example: - (id)getDelegate; // AVOID - (id)delegate; // GOOD

This is for Objective-C methods only. C++ method names and functions continue to follow the rules set in the C++ style guide.

If you have already described an interface in detail in the comments at the top of your file feel free to simply state "See comment at top of file for a complete description", but be sure to have some sort of comment.

Additionally, each method in the public interface should have a comment explaining its function, arguments, return value, and any side effects.

Document the synchronization assumptions the class makes, if any. If an instance of the class can be accessed by multiple threads, take extra care to document the rules and invariants surrounding multithreaded use.

This helps eliminate ambiguity, especially when the symbol is a common word that might make the sentence read like it was poorly constructed. E.g. for a symbol "count":

or when quoting something which already contains quotes

Instance variable pointers to objects derived from NSObject are presumed to be retained, and should be documented as weak if they are not retained by the class. However, instance variables which are labeled as IBOutlets are presumed to not be retained by the class, and should be documented as strong if the class does retain them.

Where instance variables are pointers to CoreFoundation, C++, and other non-Objective-C objects, they should always be documented in comments as strong or weak. Be mindful that support for automatic C++ objects encapsulated in Objective-C objects is disabled by default, as described here.

Examples of strong and weak documentation: @interface MyDelegate : NSObject { @private IBOutlet NSButton* okButton_; // normal NSControl IBOutlet NSMenu* myContextMenu_; // manually-loaded menu (strong) AnObjcObject* doohickey_; // my doohickey MyController* controller_; // so we can send msgs back (weak, owns me) // non-NSObject pointers... CWackyCPPClass* wacky_; // some cross-platform object (strong) CFDictionaryRef* dict_; // (strong) } @end

strong

The object will be retain'd by this class

weak

The object will be not be retain'd by this class (e.g. a delegate).

It is important for those who might be subclassing your class that the designated initializer be clearly identified. That way, they only need to subclass a single initializer (of potentially several) to guarantee their subclass' initializer is called. It also helps those debugging your class in the future understand the flow of initialization code if they need to step through it.

If you fail to override the superclass' designated initializer, your initializer may not be called in all cases, leading to subtle and very difficult to find bugs.

All memory for a newly allocated object is initialized to 0 (except for isa), so don't clutter up the init method by re-initializing variables to 0 or nil.

Unlike C++, Objective-C doesn't have a way to differentiate between public and private methods — everything is public. As a result, avoid placing methods in the public API unless they are actually expected to be used by a consumer of the class. This helps reduce the likelihood they'll be called when you're not expecting it. This includes methods that are being overridden from the parent class. For internal implementation methods, use a category defined in the implementation file as opposed to adding them to the public header.

Before Objective-C 2.0, if you declare a method in the private @interface, but forget to implement it in the main @implementation, the compiler will not object. (This is because you don't implement these private methods in a separate category.) The solution is to put the functions within an @implementation that specifies the category.

If you are using Objective-C 2.0, you should instead declare your private category using a class extension, for example:

which will guarantee that the declared methods are implemented in the @implementation section by issuing a compiler warning if they are not.

Again, "private" methods are not really private. You could accidentally override a superclass's "private" method, thus making a very difficult bug to squash. In general, private methods should have a fairly unique name that will prevent subclasses from unintentionally overriding them.

Finally, Objective-C categories are a great way to segment a large @implementation section into more understandable chunks and to add new, application-specific functionality to the most appropriate class. For example, instead of adding "middle truncation" code to a random object in your app, make a new category on NSString).

While it may seem tempting to include individual system headers from a framework such as Cocoa or Foundation, in fact it's less work on the compiler if you include the top-level root framework. The root framework is generally pre-compiled and can be loaded much more quickly. In addition, remember to use #import rather than #include.

While ever so slightly slower, this prevents someone from accidentally removing the release or inserting a return before it and introducing a memory leak. E.g.:

When assigning a new object to a variable, one must first release the old object to avoid a memory leak. There are several "correct" ways to handle this. We've chosen the "autorelease then retain" approach because it's less prone to error. Be aware in tight loops it can fill up the autorelease pool, and may be slightly less efficient, but we feel the tradeoffs are acceptable.

Never just retain the string. This avoids the caller changing it under you without your knowledge. Don't assume that because you're accepting an NSString that it's not actually an NSMutableString.

We do compile with -fobjc-exceptions (mainly so we get @synchronized), but we don't @throw. Use of @try, @catch, and @finally are allowed when required to properly use 3rd party code or libraries. If you do use them please document exactly which methods you expect to throw.

Do not use the NS_DURING, NS_HANDLER, NS_ENDHANDLER, NS_VALUERETURN and NS_VOIDRETURN macros unless you are writing code that needs to run on MacOS 10.2 or before.

Also be aware when writing Objective-C++ code that stack based objects are not cleaned up when you throw an Objective-C exception. Example:

will give you:

Note that the destructor for a never got called. This is a major concern for stack based smartptrs such as shared_ptr and linked_ptr, as well as any STL objects that you may want to use. Therefore it pains us to say that if you must use exceptions in your Objective-C++ code, use C++ exceptions whenever possible. You should never re-throw an Objective-C exception, nor are stack based C++ objects (such as std::string, std::vector etc.) allowed in the body of any @try, @catch, or @finally blocks.

Use nil checks for logic flow of the application, not for crash prevention. Sending a message to a nil object is handled by the Objective-C runtime. If the method has no return result, you're good to go. However if there is one, there may be differences based on runtime architecture, return size, and OS X version (see Apple's documentation for specifics).

Note that this is very different from checking C/C++ pointers against NULL, which the runtime does not handle and will cause your application to crash. You still need to make sure you do not dereference a NULL pointer.

Only use the constants YES and NO for BOOL return values and assignments. Common mistakes include casting an array's size or a pointer value as a BOOL, which depending on the value of the last byte, could still result in a NO value.

Also be careful when interoperating with C++ and its bool type. Don't just assume that YES and NO map directly to true and false. You can use the ternary operator to succinctly map between them.

Finally, don't directly compare BOOL variables directly with YES. Not only is is harder to read for those well-versed in C, the first point above demonstrates that return values may not always be what you expect.

A class that implements the delegate pattern should:

1. Have an instance variable named delegate_ to reference the delegate.
2. Thus, the accessor methods should be named delegate and setDelegate:.
3. The delegate_ object should not be retained.

• Separate model from view: don't build assumptions about the presentation into the model or data source. Keep the interface between the data source and the presentation abstract. Don't give the model knowledge of its view. (A good rule of thumb is to ask yourself if it's possible to have multiple presentations, with different states, on a single instance of your data source.)
• Separate controller from view and model: don't put all of the "business logic" into view-related classes; this makes the code very unusable. Make controller classes to host this code, but ensure that the controller classes don't make too many assumptions about the presentation.
• Use a protocol for callback APIs where all the methods must be implemented. Use a category (or an "informal protocol") when not all the methods need to be implemented.