Difference between class property mVar and instance variable self.mVar

Question

I am some what confused as to the difference between accessing an instance variable via self or just by name (when working inside the class).

For instance, take this class:

//In .h file:
@interface Register : NSObject {
    NSString *mName;
}

- (id) initWithName:(NSString *) name;

//In .m file:
- (id) initWithName:(NSString *)name
{
    if (self == [super init])
    {
        mName = name;
    }
    return self;
}

What's the difference between accessing the instance variable via

self.mName = name;

vs

mName = name;

Which isn't a @property and is not @sythenize'd.

Say it is this though, per this example:

//In .h file:
@interface Manange_My_ViewsViewController : UIViewController { 
    IBOutlet UILabel *countLabel;
}

@property (nonatomic, retain) IBOutlet UILabel *countLabel;

//In .m file:
@synthesize countLabel;

- (void) updateLabel:(NSUInteger)count
{
    countLabel.text = [NSString stringWithFormat:@"%d", count];
}

But say I accessed countLabel as:

self.countLabel

What would be the difference?

Edit: Third example per users' answer: Say it the iVar wasn't an IBOutlet:

//In .h file:
@interface Fake : NSObject {
    NSString *mVar;
}
@property (nonatomic, retain) NSString *mVar;

//In .m file:
 @synthesize mVar;

 mVar = @"";

VS

 self.mVar = @"";

Or is it the same - that in the first we are accessing the actual instance variable and in the second we're actually going through the auto created setter (via @synthesize)?

Thanks all!

Edit: Update in response to Peter Hosey ...

So your thinking the convention of mVarName is bad? I took that from my C++ days.

But what about the case when you do?

-(void) someMethod:(int) x
{
    x = x;
}

You can't do that (Say 'x' is also a class variable)

But you can do:

-(void) someMethod:(int) x
{
    mX = x;
}

But your saying its better to do:

-(void) someMethod:(int) x
{
    self.x = x;
}

Answer 1

What's the difference between accessing the instance variable via

self.mName = name;

vs

mName = name;

The first is property access syntax. It translates to an accessor message to the object (in this case, self). That is, that statement implicitly translates to this message expression statement:

[self setMName:name];

(Awkward accessor names like that are why “mName” is a poor name for a property. There is property declaration syntax to work around that, letting you name the property “name” and your instance variable “mName” and map one to the other.)

The second example directly accesses the instance variable—no accessor message.

Which isn't a @property and is not @sythenize'd.

Say it is this though, …

If no property named “mName” is declared for a class, then you can't use property access syntax to access a property by that name on an instance of that class.

And it doesn't matter whether you synthesize the accessors, hand-wave them to a superclass with @dynamic, or define them yourself. That's how the object will respond to the accessor message, but the accessor message the compiler generates will be no different (since a property access could just as easily come from outside the class as from inside it).

Say it the iVar wasn't an IBOutlet:

That doesn't matter. IBOutlet only means anything to IB. Everything else doesn't care.

In fact, IBOutlet is currently just a macro that expands to nothing. After your code gets preprocessed, the word “IBOutlet” is no longer there, so the compiler never sees it. That's how little a difference it makes to anything but IB: None at all.

Edit in response to question edit

I said mName is bad as a property name, because of the accessor names that follow from it. The name of an instance variable is a separate issue, particularly since the property and ivar don't have to have the same name.

For a variable, be it an instance variable or a local variable, the choice of name or m_name or mName is purely a style choice.

someMethod: is generally the accessor, setX:. Within that method, self.x = x, which is [self setX:x], causes infinite recursion. So don't do that.

When someMethod: isn't the accessor (or init or dealloc), using the property is just fine and generally preferable. However, in that case, you're not likely to give one of its arguments the same name as an instance variable. When such a case could occur, name the local variable more specifically, because its purpose is more specific. This, too, is a style issue.

When it is the accessor, I name the local variable newX, having named the instance variable the same as the property, x. This is my own personal style; as I said, naming the property x, the ivar mX, and the local variable x is fine too (aside from the excessive brevity of this example).