Using self->ivar when accessing instance variables directly

Question

I have noticed that most Objective-C coders never use the self->ivar syntax when accessing instance variables directly. Most sample code that I see simply references the instance variable without self->. I think that it is rather confusing to reference an instance variable without making clear that it is an instance variable and not simply a variable of the current scope.

I feel like I want to write stuff like:

- (void)dealloc {
    [self->someVar release];
    [self->anotherVar release];
    [super dealloc];
}

or

- (void)setVar:(Foo *)newVar {
    [self->var autorelease];
    self->var = [newVar retain];
}

There aren't a whole lot of occasions when we ever even should access our instance variables without using an accessor for encapsulation, but sometimes we need to such as in dealloc, or in custom getters and setters.

Am I a bad person/programmer for doing this? Is there some really good reason for not writing code like this? Because it feels really good to do it this way.

Answer 1

There's no reason you shouldn't write it that way. I think people tend to write it the other way because they try to avoid shadowing their ivars anyway, so there shouldn't be any ambiguity in what variable they're talking about — and it's shorter.

Answer 2

Chuck is correct in that there's no technical reason you shouldn't write it that way, unless you're shadowing ivars with local variables, which is is generally a bad idea. However, it's arguable that omitting self-> is stylistically cleaner, and it certainly results in less verbose code. Personally I would find the self-> to be distracting (especially if the code is well-designed and variables are well-named) but if it makes things more understandable for you, by all means do it. Just be aware that if you show your code to other Objective-C programmers, they're likely to have a conflicting opinion, so it's good to have a think skin. Besides, most programmers find that their perception of what makes code "feel good" changes over time and with experience, and those opinions often mellow out with age. :-)

Answer 3

Short answer: No, you are not a bad programmer because of that :) There is also no good reason for not writing code this way; most programmers are simply lazy or never really have written an exhausting method in their whole life.

Long answer: Technically when you access a variable without "self->", the compiler will first for a variable of that name in the local scope and if it cannot find one, it will repeat that search with instance variables. If it finds a hit there, it will actually generate code as if "self->..." had been written there. If there was no match for instance variables either, the compiler would try within global scope, BTW.

Most programmers only read their own code and they know pretty well what is an instance variable and what not. Once you ever had to work with code you have not written yourself, where the method is 4 screen pages long (and I have a bigg screen), you are really thankful when the programmer made it absolutely clear on every variable access: Is that variable a parameter fed to the method call, a local variable of this method, an instance variable of the object or possibly a global variable (only global to all instances of this class or possibly application global). You are thankful, because if there are just a bunch of variables with similar name and with no special naming or access pattern, however all of different type, you pretty quickly lose oversight. And relying on the fact that Xcode syntax highlighting highlights instance variables in a different way than local variables is also stupid, because no programmer is forced to edit code in Xcode to begin with and even if he does, he may have a color scheme where instance variables are the same color as local ones.

Accessing instance variables via self-> is perfectly fine, but consider also a to maybe use a prefix/suffix, which will also make obvious those are instance variables and also avoid naming conflicts with method parameters or local variables.