Instance variable naming conventions in Cocoa

Question

This question is about variable naming style in objective c and cocoa. I just want to stress that I'm not looking for a "right" answer, just good ideas.

I've read through Apple and Google's objective c style guides and I'm not really happy with either of them. Apple's guide doesn't have any real style recommendations regarding instance variables vs local variables. In fact, the Cocoa library itself seems perfectly happy having function parameters of the exact same name as instance variables. That makes me cringe personally.

Googles guide specifies that instance variables should be indicated with a trailing underscore. Alright, all well and good, but it suggests that we then synthesize every public property with @synthesize property = property_. I don't know about anyone else, but I'll be damned if I'm going to do that for every instance variable in my project. I think it's a wasteful and confusing solution.

I'm tempted to go with the myX (eg "myInstanceVariable") naming style for object properties, but I have rarely seen that style in objective c.

So yeah, what do you use? Any style conventions out there I don't know about that you've found useful? Do you think function parameters with the same name as instance variables is dangerous, especially in multiple developer environments? Thanks guys and gals!

NOTE - As many people have pointed out, my terminology was off in the OP. Apologies if the original wording hurt the clarity, but I think the point was still clear.

Answer 1

m_variableName is pretty common too for member variables. Personally, most of the time, I just go with the same name for both variables and making the distinction between this.varname and varname.

Answer 2

In Cocoa, the style is to have pascalCased (or is that camelCased? I can never remember) names; and have the member variables be named the same as the accessor methods. (Such as NSInteger anInteger, - anInteger and - setAnInteger:).

It might not be the best style, but it's probably a good idea to get used to it if you are going to do any amount of work with Cocoa, as a number of mechanisms assume this particular kind of naming convention.

Answer 3

I tend to use non-prefixed instance variable names (note that "member variable" is a C++ism as it's suggestive of structures and classes being mainly interchangeable, which is not the case in Objective-C), and in cases where ambiguity arises, I use the Smalltalk convention of naming the parameter by its type with "a" or "an", e.g.:

- (void)setFoo:(SOFoo *)aFoo;
{
    foo = aFoo;
}

(of course, in modern ObjC you'd use a property for this.)

Using theFoo instead of aFoo is also somewhat common; see the answers to this question.

The Google convention makes sense if you're really worried about conflicts. If you use an Xcode text macro or tool like Completion Dictionary or Accessorizer to generate your directives, it's pretty simple to adopt.

Note that the Cocoa key-value coding guidelines pretty much assume either (a) you do not prefix/suffix your instance variable names, or (b) you implement (or synthesize) non-prefixed/suffixed accessors for them. As someone else mentioned, do not use the _ prefix; it's reserved for Apple's use in their frameworks.

Answer 4

First: there are no "member variables" in Objective-C, there are "Instance Variables" or "ivars".

Google is NOT any kind of authority on Objective-C coding or Mac development. Google Earth is a Qt app: 'nuff said.

I seem to remember seeing an official coding style guide from Apple for Objective-C, which I'm not finding at the moment. This article is a pretty good summary, though:

http://cocoadevcentral.com/articles/000082.php

Found it! Here's Apple's official coding guidelines for Cocoa:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

Answer 5

Yes, Accessorizer allows you to add a prefix or a postfix (suffix) or a combination of the two - and it will automatically generate the correct synthesize statements for key-value coding wrt to any prefix or postfix detected. Accessorizer does a lot more: Accessorizer will write not just your property code but your explicit accessors when you need to override, and it will help provide you with the init, keypath, keyed-archiving, indexed accessors, accessors for unordered collections such as NSSet, copyWithZone, KVO, key-validation, singleton overrides, dealloc, setNilForKey, non-standard attribute persistence (Core Data), locking, headerdoc, convert method to selector, NSUndoManager methods and more including IBOutlet Detection, setting your UIKit views to nil in -viewDidUnload {...}, sorting your ivar declarations, property and synthesize statements, -dealloc {...} and -viewDidUnload {...} methods. Accessorizer also provides a caching mechanism for the custom table when working with properties.