What do you call your instance / parameter values?

Question

Being new to the Objective-C programmer (but long-term C / ++), I am looking for tips / tricks on variable naming conventions.

My personal preference would be to use a prefix for instance variables, both for clarity inside functions, and to prevent shadowing of function parameters. However, I'm a fan of properties that excludes prefixes (unless you also prefix your property names that don't work too well and look silly). Similarly, I could use the "self.variable" convention, but only if I do the ALL property.

So, give the code below what is the preferred naming style for instance / function variables? And if you are not worried, how do you deal with shadow monitoring of function parameters?

@interface GridItem : NSObject { CGRect _rect; ... } @end -(void) initFromRect:(CGRect)rect { _rect = rect; ... } 

Hooray!

Answer 1

In most Cocoa projects, using the underbar as the prefix for the instance variable is not an IBOutlet and does not use the prefix for the instance variables of IBOutlet .

The reason I don't use substructures for IBOutlet instance variables is because when you load the nib file, if you have a setter method for the plugged socket, this setter will be called. However, this mechanism does not use key encoding; therefore, an IBOutlet whose name has a prefix with a lower bar (for example, _myField ) will not be set if the installer is not named exactly like the output (for example, set_myField: , it is standard and rude.

Also, keep in mind that using properties like self.myProp does not match access to instance variables. You send a message when using the property, as if you used parenthesized notation, for example [self myProp] . All properties give you a brief syntax for specifying both getter and setter on one line and allow you to synthesize their implementation; they do not actually close the message sending mechanism. If you want to access the instance variable directly, but prefix with self , you need to consider self as a pointer, for example self->myProp , which is really access to the C-style field.

Finally, never use Hungarian notation when writing Cocoa code and avoid other prefixes such as "f" and "m_" - this will mean that the code was written by someone who does not "receive it" and force it View suspicion by other Cocoa developers.

In general, follow the recommendations in the Coding Guide for a Cocoa document in Apple Developer Connection , and other developers will be able to pick up and understand your code, and your code will work well with all Cocoa functions that use runtime introspection.

A window controller class might look like this using my conventions:

 // EmployeeWindowController.h #import <AppKit/NSWindowController.h> @interface EmployeeWindowController : NSWindowController { @private // model object this window is presenting Employee *_employee; // outlets connected to views in the window IBOutlet NSTextField *nameField; IBOutlet NSTextField *titleField; } - (id)initWithEmployee:(Employee *)employee; @property(readwrite, retain) Employee *employee; @end // EmployeeWindowController.m #import "EmployeeWindowController.h" @implementation EmployeeWindowController @synthesize employee = _employee; - (id)initWithEmployee:(Employee *)employee { if (self = [super initWithWindowNibName:@"Employee"]) { _employee = [employee retain]; } return self; } - (void)dealloc { [_employee release]; [super dealloc]; } - (void)windowDidLoad { // populates the window controls, not necessary if using bindings [nameField setStringValue:self.employee.name]; [titleField setStringValue:self.employee.title]; } @end 

You will see that I use an instance variable that references Employee directly in my -init and -dealloc , while I use the property in other methods. This is usually a good template with properties: just ever touch the base instance variable for the property in initializers, in -dealloc , and in getter and setter for the property.

Answer 2

I follow Chris Hanson's advice regarding the ivar underscore prefix, although I admit that I use underscores for IBOutlets. However, I recently started IBOutlet declarations in the @property line as suggested by @mmalc . The benefit is that all my ivars now have an underscore, and the standard KVC setters are called (i.e. setNameField: . In addition, output names do not have underscores in Interface Builder.

 @interface EmployeeWindowController : NSWindowController { @private // model object this window is presenting Employee *_employee; // outlets connected to views in the window NSTextField *_nameField; NSTextField *_titleField; } - (id)initWithEmployee:(Employee *)employee; @property(readwrite, retain) Employee *employee; @property(nonatomic, retain) IBOutlet NSTextField *nameField; @property(nonatomic, retain) IBOutlet NSTextField *titleField; @end 

Answer 3

You can use a lower level prefix on your ivars and still use a non-subscript name for your properties. For synthesized accessories, simply do the following:

 @synthesize foo = _foo; 

This tells the compiler to synthesize the foo property using the_foo ivar.

If you write your own accessors, then you simply use the base word ivar in your implementation and save the name of the method other than underbar.

Answer 4

Personally, I follow Cocoa's naming conventions using the camel body for functions and variables and the capitalized camel body for object names (without a leading NS, of course).

I find that a type prefix makes the code more opaque to everyone who hasn't written it (since everyone invariably uses different prefixes), and in a modern IDE, it's really not that hard to understand something like that.

Answer 5

With the introduction of properties, I do not see the need for the prefix "_" for class instance variables. You can set a simple rule (described in your header file) that any variables that need access to the appearance of the class must access, through a property or using custom class methods to influence values. This seems a lot cleaner to me than names with "_s" stuck in front. It also encapsulates values ​​correctly so you can control how they are changed.

Answer 6

I don't like using underscores as prefixes for any identifiers, because C and C ++ save some underscore prefixes for use in the implementation.

I think using self.variable is ugly.

In general, I use unvarnished identifiers (i.e. not prefixes and suffixes) for instance variables. If your class is so complex that you cannot remember instance variables, you have problems. Therefore, for your example, I would use "rect" as the name of the instance variable and "newRect" or "aRect" as the parameter name.

Answer 7

Andrew: Actually, there are many Cocoa developers who don't use instance variable prefixes at all. This is also extremely common in the Smalltalk world (in fact, I would say that in Smalltalk you can hardly hear the use of prefixes for instance variables).

The prefixes of instance variables always hit me like C ++ - ism, which was ported to Java and then to C #. Since the world of Objective-C was pretty much parallel to the world of C ++, where, since the worlds of Java and C # are its successors, this explains the “cultural” difference that you can see on this between different sets of developers.

Answer 8

My style is a hybrid and really a break in the days of PowerPlant:

The most useful prefixes I use are "in" and "out" for function / method parameters. This will help you understand that the parameters are at a glance and really helps prevent conflicts between the method parameters and instance variables (how many times have you seen that the table parameter conflicts with an instance variable with the same name). For instance:.

 - (void)doSomethingWith:(id)inSomeObject error:(NSError **)outError; 

Then I use a simple name for variable names and property names:

Then I use "the" as a prefix for local variables: theTable, theURL, etc. Again, this helps to distinguish between local and instance variables.

Then, after styling PowerPlant, I use several other prefixes: k for constants, E for enumerations, g for globals, and s for statics.

I have been using this style for something like 12 years.

Answer 9

Although I like to use the underscore prefix for ivars, I hate writing @synthesize strings due to all the duplication (this is not very DRY ). I created a macro to help do this and reduce code duplication. Thus, instead of:

 @synthesize employee = _employee; 

I am writing this:

 ddsynthesize(employee); 

This is a simple macro that uses the addition of a token to add an underscore on the right side:

 #define ddsynthesize(_X_) @synthesize _X_ = _##_X_ 

The only drawback is that it will confuse the Xcode refactoring tool and it will not be renamed if you rename the property by refactoring.

Answer 10

Along with what has been said here, be sure to read the Cocoa documentation for the name corresponding to the Key Value Observing. Strictly following this pattern will help you in the long run.