When do you make an underscore in front of an instance variable?

Question

Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?

I've seen this at Apple, inside UIPickerView.h:

id<UIPickerViewDataSource> _dataSource;

why's that underscore there? Does it have a special meaning? A Convention I must know about?

Answer 1

A lot of people use this for private variables, to differentiate between private variables and public variables within an object.

It is a completely optional way of working.

Answer 2

What you're seeing is the use of underlines to distinguish between instance variables and properties. So a class declaration might be:

@interface Foo {
  NSString* _label;
  ....
}

@property (nonatomic, retain) NSString* label; // notice: no underline

Then in the implementation file you would have:

@synthesize label=_label; // the property is matched with the ivar

Now when inside the implementation, if you want to access the instance variable directly you could just use _label but to go through the property accessor methods (which take care of retain/releases and a bunch of other book-keeping tasks) you would use self.label. From the outside, you would always want to go through the {object}.label property.

The other way is to do without the underline and just use:

NSString* label;
@property (nonatomic, retain) NSString* label;
...
@synthesize label;

It works the same but then it might confuse someone reading the code and trying to keep track of label vs self.label. I personally find the Apple convention (with underlines) a bit easier to read but it's a matter of preference.

Answer 3

As people said already _someVar was used to say that a variable was private. It was a simple matter of convention and doesn't really matter.

One other use, taking a trip in the wayback machine in C a _function() represented a function that wasn't platform portable and __function() represented a function that wasn't compiler portable. So, in the standard C library, you will sometimes see a variable with a _ or __ infront of the name, this is what those functions represent.

Answer 4

It's sometimes used to denote private variables. More generally it just means "this variable is different somehow".

Answer 5

can it be that... (jogging memory)...

i vaguely remember reading an ADC document explaining that apple reserves the usage of underscore-prefixed member variables? and that 3rd party developers are discouraged from using this convention so as to avoid collisions?

|K<

Answer 6

I use underscores to denote that a variable is a member, similar to the 'm' prefix in Hungarian notation (which notation I despise thoroughly, but that's another story). Sure you get colour-coding editors these days, but my opinion is that the prefix makes you think about the variable being a member/instance one before you type it, not just sometime afterwards when it gets colour-coded by your editor.

Answer 7

Generally it's to denote that a variable should not be directly touched by a developer. It's not really a requirement but it's good practice if you can't avoid having a public variable in a class that you don't want messed with.

Answer 8

I choose to use underscores for ivars because I often come across the following situation:

@interface MyClass:NSObject
{
    NSUInteger count;
}

@property(nonatomic) NSUInteger count;  

-(id) initWithCount(NSUInteger) count;


@end

(...)

@implementation MyClass
@synthesize count;

-(id) initWithCount(NSUInteger) count
{
    if((self = [super init])){
        self.count = count; // Parameter name collides with ivar name!
    }
    return self;
}

@end

So I do this:

@interface MyClass:NSObject
{
    NSUInteger _count;
}

@property(nonatomic) NSUInteger count;  

-(id) initWithCount(NSUInteger) count;

@end

(...)

@implementation MyClass
@synthesize count = _count;

-(id) initWithCount(NSUInteger) count
{
    if((self = [super init])){
        _count = count; // No name collision
    }
    return self;
}

@end

Of course, I could alternatively change the parameter name to "newCount" or "aCount" (I hate that one). I think it's a matter of taste.