Professional Documents
Culture Documents
Once you've figured out the basics of Objective-C and Cocoa, you're ready to start
writing some code. But the conventions of naming and formatting Objective-C code
are not the same as traditional C, C++ or even Java programs.
Apple has laid out a set of guidelines as to how code should be written for
maximum clarity and integration with the frameworks. In addition, there are some
undocumented conventions that Cocoa developers often use.
In essence, the human factor present in Apple's products for the end user can be
found in Objective-C and Cocoa themselves.
1 of 7
In the earlier days of software development, the average program was made up of
far less code. With smaller functions and fewer variables, it was understood that
cp meant character pointer and fread() indicated a function that read data from a
file. Since space on terminal screen was limited, short names made the most sense.
Newer programs, though, have many more variables and functions. In this
environment, a short name becomes ambiguous, which lends itself to buggy code.
Xcode and other editors will autocomplete long names for you.
Cocoa Classes
NSPasteboard
NSCell
NSComboBox
NSComboBoxCell
NSMenuItem
NSMenuItemCell
Cocoa strongly encourages expressive, clear, non-ambiguious names. Take a look at
the classes listed in the table to the left. You have some idea of what they do
just from their name.
Also notice how some are combinations of other class names. NSMenuItemCell
suggests a cell which is used by a menu item.
Naming consistency isn't extra credit, it's an essential part of being a great
Cocoa programmer. Remember, since you do far more reading of code than writing,
invest the time to type an extra eight characters.
2 of 7
Class Names
Standard Classes
NSString
NSMutableArray
NSDictionary
Custom Classes
CDCRecipient
CDCEmail
CDCEmailAttachment
Custom Subclasses
CDCTableView
CDCOutlineView
CDCArrayController
Whether they're a standard part of Cocoa or your own creation, class names are
always capitalized.
Objective-C doesn't have namespaces, so prefix your class names with initials.
This avoids "namespace collision," which is a situation where two pieces of code
have the same name but do different things. Classes created by Cocoa Dev Central
would probably be prefixed with "CDC".
If you subclass a standard Cocoa class, it's good idea to combine your prefix with
the superclass name, such as CDCTableView.
Most of the standard Cocoa classes begin with NS for historical reasons, as Cocoa
is based on the NeXTSTEP development framework.
3 of 7
Variable Names
Variable names start with lower-case letters, but are internally capitalized
wherever a new word appears:
Correct
NSString * hostName;
NSNumber * ipAddress;
NSArray * accounts;
Incorrect
4 of 7
In terms of real-world practice, a variable name usually does not indicate the
type if it is something common like NSString, NSArray, NSNumber or BOOL.
Correct
NSString * accountName;
NSMutableArray * mailboxes;
NSArray * defaultHeaders;
BOOL userInputWasUpdated;
NSString * accountNameString;
NSMutableArray * mailboxArray;
NSArray * defaultHeadersArray;
BOOL userInputWasUpdatedBOOL;
If a variable is not one of these types, the name should reflect it. Also, there
are certain classes that you only need one instance of. In this case, just name
the variable based on the class name. Font manager is a good example of this.
NSDictionary * keyedAccountNames;
NSDictionary * messageDictionary;
NSIndexSet * selectedMailboxesIndexSet;
Admittedly, this is a bit of a grey area.
5 of 7
Method Names
Methods are perhaps the most important topic we can talk about. Most object-
oriented languages use a syntax like:
object.begin(resource);
object.processData(resource, data, true);
object.end(true);
While these methods names are easy to write the first time, the actual behavior is
not clear. This is much more of a problem amidst massive amounts of surrounding
code.
Cocoa programmers think from the end, choosing a method name based on how it will
look in actual use. Let's say I want to write an in-memory file object written to
disk. In some languages, that would look like this:
Programmers do much more reading of code than writing, so Objective-C and Cocoa
are designed to read well. Reading a message as a phrase is a good way to test
your method name:
6 of 7
Correct!
- (NSString *) name;
- (NSString *) color;
Incorrect
- (NSString *) getName;
- (NSColor *) getColor;
Adjectives
Not all accessors return values like name, date, height, etc. Some represent a
particularly quality of an object. These are often represented by BOOLs.
For example, "selectable". In Objective-C, the getter for this key is called
-isSelectable, but the setter is -setSelectable:
// if textview is editable.
if ([textView isEditable])
[textView setEditable: NO];
Keep in mind that naming your accessors according to all of these rules isn't
purely an issue of clarity and aesthetics. Cocoa relies heavily on key-value
coding for much of its magic, and KVC relies on properly-named accessors.
7 of 7
Abbreviations
You've probably noticed that the general principle here is to spell things out to
avoid confusion. However, there are times where acronyms are so well-known that
spelling them out either doesn't help or can actually create confusion.
#define MAX_ENTRIES 20
#ifdef ENABLE_BINDINGS_SUPPORT