Objective-C properties using ARC

Question

Im just about to refactor my current iOS project to use ARC. And after previewing the changes to migrate my current code to ARC using the "Refactor to ARC" tool i xCode, i can see my current code conventions probably not suited for ARC. Because it adds alot of __weak / __strong etc to my ivars.

Heres how my current conventions are:

i define all instance variables as private or protected ivars. and all public variables i create a @property for.

@interface TestClass
{
 @private
 NSMutableArray* mArray;
 NSString* mString;
 BOOL mMyBoolean;
}

@property (retain, nonatomic) NSString* string; // public
@end

All objects i always back with a @property, to avoid dealing with release / retain so if i have a private variable that is a reference, i just create a category in the implementation. Struct (like mMyBoolean) i just leave define as a ivar.

@interface TestClass()
@property (retain, nonatomic) NSmutableArray* mArray;
@end

@implementation TestClass
@synthesize string = mString;
@synthesize mArray;

@end;

But because the new ARC is taking care of retain / release i properly dont need private variables to be backed by @property.

So what code conventions would be more appropriate? Ive been thinking about just defining properties in the interface like this:

@interface TestClass
{
 @private
 NSMutableArray* mArray;
 BOOL myBoolean;
}

@property (strong, nonatomic) NSString* string;
@end


@implementation TestClass
@synthesize string;
@end

And dont use category properties for private properties. (also i removed the "m" prefix) and i dont define the backed ivar that @property should use, instead i just let xcode use its autogenerated?.

Answer 1

This is more of a style question, so...it's hard to answer objectively, but I will throw in my two cents. There is not anything wrong with what you are doing as far as I can see. If your goal is to see what you can do to have cleaner code, then I will share my naming conventions (though one man's junk is another man's treasure, so if you don't like it then...well tough haha, you don't have to take anything away from it).

1) iVars start with m and are never public.

2) Property synthesized to a variable name starting with underbar (_), no explicit backing variable unless I need inherited classes to be able to modify a read only variable internally, in which case I need to move it to the public interface (and I still name it with an underbar to indicate to myself that it is a property variable). Properties are meant to expose some info through an interface, but since the implementation has access to everything it doesn't make sense and I never use properties in private interfaces except for the following case:

3) Properties that lazy load, or otherwise have logic outside of simply assigning to a variable. In this case, if I only override the getter or setter (not both) I will still synthesize to (_) and override the desired method (no need for explicit variable). If I override both, I don't synthesize then obviously I need an explicit backing variable (don't forget to call the KVO methods ^^).

There is no "right" way to do this kind of stuff I imagine...the only guidelines that seems to be universal are

1) Do it in a way that you and your team can understand easily

2) Do it consistently

3) In the case of an API, do it in a way that is easily understandable from looking at only the header files.