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?
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?
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.
It's sometimes used to denote private variables. More generally it just means "this variable is different somehow".
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.
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.
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.
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<
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.