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.

Putting Thought into Naming

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 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.

Class Names

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.

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.

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:

fileWrapper.write(path, true, true);

In Cocoa/Objective-C, it looks like this:

[fileWrapperwriteToFile: pathatomically: YESupdateFilenames: YES];

When creating a method, ask yourself if its behavior will be clear from its
name alone, particularly when surrounded by tens of thousands of lines of code.

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:

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.

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.