Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Name instance variables, methods and parameters.

On Jan 28, 2004, at 4:00 AM, Czarny, Eric wrote:

I know that this may be an awfully common question, but I haven't found a
single answer, nor a collection of answers, to give me a better idea. The
section on coding style within Apple's developer documentation states that
an underscore should not be used for naming private methods and instance
variables. I know I have seen this topic being discussed at CocoaDev, but
couldn't gather sufficient information. I'd like to continue to use an
underscore, but if it goes against Apple's own wishes, I'd like avoid it if
I could.


There are two different problems here which we should keep separated:

1) Prefixing your own instance variables with an '_':

You can do this without having to fear any negative consequences. Contrary to methods, every subclass-able class must declare all of its instance variables in the interface block. The technical reason for this requirement is that the compiler must be able to compute the size of a class instance so that it can correctly create and fill out a class structure for the runtime and because the compiler must be able to compute the variable offsets which are needed for the load/store machine instructions.

If you ever happen to pick a variable name for one of your instance variables which is already in use by one of the super classes of your class, then the compiler will abort compilation with a 'duplicate name' error. So there is no way that you could overlook a name clash.

I personally have been prefixing my instance variables with an underscore for the past 7 years and have never run into a single name clash. And even if I had, it wouldn't have been a problem because the compiler would have told me so. Thus, I can't really follow the logic of Apple's documentation in this case.


2) Prefixing your own methods with an '_':

Here the situation is more problematic. The real fundamental problem is that ObjC does not require that every method be declared in the interface block of a class and that it does not support access control for methods. Thus, private methods are commonly not declared in the public interface block of a class which also means that the compiler is no longer able to detect method name clashes which involve such private methods.

Because of this and because Apple has chosen to use the underscore to mark its private methods, you should not prefix your own private methods with an underscore. However, in actual practice things are not as easy and clear cut. There are a number of Cocoa classes which do have private methods that don't start with an underscore. I.e. NSView has a private method called invalidate: which does not start with an underscore. There's also a compareGeometry: method which again does not start with an underscore.

Ergo, not prefixing your method names with an underscore still does not give you any guarantee that you won't collide with a private framework method of one of your class' super classes. In my opinion, it would be better if ObjC would explicitly deal with this problem on the language level. I don't like it if languages try to solve language problems purely by unenforceable conventions. Because human being are supposed to follow those conventions and they make mistakes.

At least Apple should have chosen another prefix for its own private methods like __apple_ and they should have left the simple to use prefix to us poor little third-party developers...


Regards,

Dietmar Planitzer
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >Name instance variables, methods and parameters. (From: "Czarny, Eric" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.