Am Fr,22.08.2008 um 04:59 schrieb Thomas Engelmeier:


Am 22.08.2008 um 00:59 schrieb Dave MacLachlan:

Also, are the _ in front of member variables for Apple only (so we don't stomp on each other with member var names) or are they using them for the readability reason mentioned above? There is documentation where they have claimed _ at the beginning of method names as being Apple only, but nothing about method vars, and the KVC compliance docs seem to imply that it is fine to do.

Officially it is Apple only, but everybody and his dog uses it - in consistency to quite some Apple-provided samples. Also, in C++ the _ variable prefix is reserved for stdlib- implementation. The reasoning why many people do not consider it as problematic if there is a collision with an Apple defined _ prefixed ivar is you will see an compiler error once there is a collision.

For methods OTOH, you don't get an warning but potential runtime crashes and undefined behavior.
Some people uses the leading underscore for a convention, that something is private:


@interface FrameworkClass:… {
   NSNumber* _myPrivateNumber;
}
---
@implementation …
- (void)_myPrivateMethod

Apple says, that underscored names are for apple use only. On the first sight it looks like, that this system helps avoiding collisions: Framework classes with, custom classs without underscore.

But that's not true. If you use standard accessor naming, the collision will be moved from ivars to accessors. Example:

- (void)setMyPrivateNumber:… // I'venever seen set_myPrivateNumber:

When you subclass a framework class and "accidentially" add your own ivar "myPrivateNumber", you usually will have a setter:
- (void)setMyPrivateNumber:…

The compiler wouldn't warn, because the ivars have different names. The "new" setter to the new ivar looks like overwriting to the compiler and he wouldn't warn again. So you have a collision without any warning of nobody. The "underscore solution" makes it worse, not better …

In former times this was the reason to me, to break with the apple convention and use the underscore, too. In this case the compiler will warn me because of the double ivar. (There is no ivar overwrtiting in Objective-C.) However I stopped doing so, because it is against the rule, unusual for most readers and the risk of a conflict is not that high, if you choose your ivars with some care about this problem. So do not use names like "count" and so on, but "countOfPersonsStored" (just an example) and so on.

But IMHO, it would be a good idea, that apples stops with the underscore rule, too.

Cheers,
Amin







_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]

Amin Negm-Awad
[EMAIL PROTECTED]




_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to