Re: warning: local declaration hides instance variable
Re: warning: local declaration hides instance variable
- Subject: Re: warning: local declaration hides instance variable
- From: Wincent Colaiuta <email@hidden>
- Date: Tue, 4 Sep 2007 02:44:03 +0200
El 3/9/2007, a las 23:09, Laurence Harris escribió:
On Sep 3, 2007, at 3:30 PM, Wincent Colaiuta wrote:
El 3/9/2007, a las 20:52, Laurence Harris escribió:
An even better solution would be to rename your instance
variables with a standard naming convention that clearly
identifies them as instance variables. Since they're also
referred to as member variables, a lot of people prefix their
names with an "m":
Depends on what you mean by "a lot"; if you mean "multiple people"
then you're right. But "some" would probably be a less misleading
choice because this pattern is most definitely only in minority
use in the Objective-C world (where they are called instance
variables, not member variables, in any case).
Is there a practical reason for people in the Obj-C world to not
use this? If they prefer a differ convention, then that's fine. But
to just say they don't normally use one is hardly a good reason to
shun a potentially beneficial practice.
No, no there's no *substantial* practical reason, it's almost
entirely convention. One (minor) practical concern is that Key-Value
Coding, in the absence of accessors, will try to directly access
instance variables based on the key name; that is, a message send
like this:
[object setValue:@"John" forKey:@"name"];
Will look for an instance variable called name or _name if there is
no setName: accessor (see <http://developer.apple.com/documentation/
Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html>). So with
your scheme that wouldn't work; you'd either need to provide
accessors, use Objective-C 2.0 properties, or use ugly key names like
"mName". Not a big deal, but it is one thing to bear in mind.
Seems of dubious value to embed this information in your variable
names when the compiler is (obviously) capable of warning about
possible ambiguities, and the predominant use of accessors means
that direct instance variable manipulation is a fairly rare thing
anyway (think Key-Value Coding, and Objective-C 2.0 properties).
The main value is not to prevent errors of the kind that started
this thread. The main value to me is in making code clear and
readable. I find it much easier to follow what a method/member
function is doing and how and when it's affecting instance/member
variables when using a naming convention that clearly identifies them.
Well, like I said, direct instance variable manipulation shouldn't be
that common anyway; more often than not what kind of variable
something is is going to be (or can be made) explicit from the context:
[object setValue:[NSNumber numberWithBool:YES] forKey:@"foo"]; // KVC
[object setFoo:YES]; // accessor
object.foo = YES; // Objective-C 2.0 property
self.foo = YES; // property again
self->foo = YES; // instance variable
foo = YES; // instance? local?
aFoo = YES; // probably local (convention)
As you said, best to write code correctly the first time rather than
leaning on the compiler to catch your mistakes for you, but an
intelligent tool should provide adequate syntax coloring to help your
differentiate these things continuously, before you even hit the
"Build" button.
Cheers,
Wincent
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden