2

Is there some purpose for this convention?

StoneBreaker
  • 723
  • 10
  • 19

2 Answers2

2

There are some developers who use the following convention of "hiding" there ivars by the following method:

@interface

@private
NSString *_myString
@property (nonatomic, retain) NSString *myString;

@implementation
@synthesize myString = _myString.

what this does is disallow direct access to the ivar with forcing all access via the property myString. Its a way of hiding the internals of your class and abiding by the object oriented principle of encapsulation.

ennuikiller
  • 46,381
  • 14
  • 112
  • 137
  • 1
    Disallow is a strong word, it makes it visually obvious that you are accessing the iVar as opposed to an accessor. Nothing is stopping the user from accessing `_myString`. – Marcus S. Zarra Aug 23 '10 at 00:51
  • @Marcus ... except the @private designation! – ennuikiller Aug 23 '10 at 00:57
  • From the class, or from other classes? The class ought to know its internals; other classes can't access @private ivars. – tc. Aug 23 '10 at 00:58
  • obviously from other classes!! – ennuikiller Aug 23 '10 at 00:59
  • whoever left the downvote, but kind enough to explain why......seems rather capricious..... – ennuikiller Aug 23 '10 at 01:01
  • The downvote was mine. You will do just as well calling the ivar _myString; the @private means it can't be accessed from other classes so there really is no point in using Apple-reserved names. – tc. Aug 23 '10 at 01:08
  • The downvote is silly. The convention explained is a very common one. I use it all the time to make sure that there is no confusion about `myString` and `self.myString`. – Stefan Arentz Aug 23 '10 at 02:17
  • Also, ivars with an underscore are not 'Apple Private'. Only methods with a leading underscore are. – Stefan Arentz Aug 23 '10 at 02:18
  • @ennuikiller Even with the @private it doesn't actually stop access to the iVar. In fact, it won't even produce a warning from internal access. It is a *suggestion* for external access. Doesn't stop object->_myString from working. – Marcus S. Zarra Aug 23 '10 at 17:08
  • @tc The down-vote is definitely inappropriate. The answer is solid and underscore on iVars **used to be** reserved by Apple but they withdrew that reservation when @property was introduced. – Marcus S. Zarra Aug 23 '10 at 17:11
0

Apple likes to use underscores to mean "private", according to the Coding Guidelines for Cocoa:

Avoid the use of the underscore character as a prefix meaning private, especially in methods. Apple reserves the use of this convention. Use by third parties could result in name-space collisions; they might unwittingly override an existing private method with one of their own, with disastrous consequences.

Method names beginning with underscores are reserved according to The Objective-C Programming Language (which means they're reserved even if you don't use Cocoa, presumably):

Method names beginning with “_”, a single underscore character, are reserved for use by Apple.

Additionally, the C/C++ convention is that leading underscores are (often) reserved for the implementation. A lot of people misinterpret this and use _ for anything "private"; leading to the proliferation of _FooLog() calls in a large chunk of our codebase, even though it invokes undefined behaviour.

The only reason to do it is to discourage direct ivar access in your own class. Prevent ivar access from other classes with @private.

tc.
  • 33,468
  • 5
  • 78
  • 96