views:

1184

answers:

7

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?

+17  A: 

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.

Reed Copsey
Apple reserves variables starting with _ for its own uses. Don't do it.
Georg
I'd +1 gs's comment if I could.
Abizern
@gs (or Abizern): Do you have a reference for this? I know the compiler uses the C standard name mangling, which will add an underscore, but that doesn't prevent you from doing this in your own code base as well...
Reed Copsey
gs is incorrect, instance variables starting with _ are fine. Method names starting with _, however, are reserved by Apple.
Chris Hanson
I trust Chris, he would definitely know. My rule is to be cautious about naming (with or without underscore) when subclassing, *particularly* if you happen to subclass code from Apple or third party.
Quinn Taylor
+1  A: 

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

Spencer Ruport
A: 

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.

CarbonX
There is the @private keyword for instance variables in a class implementation that does this.
Abizern
+2  A: 

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.

Serapth
+9  A: 

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.

Ramin
Thanks. Personally, I don't like that underline-mess ;)
Thanks
Not entirely — people use "_" in any number of programming languages, and did so in Objective-C long before properties were added. This is only one possible use, but there are many others. Some people prefer to use "_" for all instance variables, or only private variables, or whatever. Personally, it's not my style either.
Quinn Taylor
I just spent ages tracking down a memory management issue due to a variable not being retained since I was using timer instead of self.timer. After this experience, I strongly recommend the use of an _ in front of all private variables
Casebash
Thanks for this explanation, I was baffled myself. All clear now.
Calvin L
+1  A: 

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<

kent
Collisions? When subclassing? That might make sense.
Thanks
Incorrect. It is underbar-prefixed method names that are reserved, not instance variable names. (Objective-C doesn't use the term "member.")
Chris Hanson
@chris: thank you very much for clearing this up for me.
kent
A: 

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.

Jim Dovey