views:

34

answers:

2

This is a style question:

Because Apple reserves the "_" privatization for its keywords, I was thinking of something along the lines of the following:

#import <Cocoa/Cocoa.h>

#define _(name) pvt_##name

@interface SFMeasureViewController : NSViewController {
    @private
    NSTextField *_(label);

}

@property (retain) IBOutlet NSTextField *label;

@end


@implementation SFMeasureViewController

@synthesize label = _(label);

@end

This is to help force the difference between [self label] and using label when it comes to retaining, and disposing of the variable properly. Here, using the term "label" within the code returns an error, forcing the user to distinguish between a call to self.label or _(label).

Now _(label) contains 2 more characters (shift-characters at that) than _label does. Is there any other good conventions out there? vLabel? Nothing is as quite as clear as _label but since its reserved, I don't want to use it.

Thoughts, critiques? This is for a style guideline at work, for primarily C++ work using Objective-C++ when necessary.

Thanks,

A: 

Actually, it is not hard to distinguish label/self.label inside of module, so I doesn't see any problem in using the same name for property and field.

Nickolay O.
well, it is. `label = nil;` != `self.label = nil;` I'm trying to avoid n00b errors and sealing up as best I can memory leaks.
Stephen Furlani
Yeah, I know that label = nil != self.label = nil. But I mean, that you, knowing that, can easily write correct code.
Nickolay O.
I can - it doesn't mean the n00bs on my team can, or that I always will after a late night playing ME2.
Stephen Furlani
A: 

Well, Apple recommends not to use _ as the first letter of anything, especially on method names. But as for instance variables, they themselves go against this principle in their sample codes. So I think _... is perfectly fine for that, without making the macro. I like the property names var vs. the backing instance variable theVar, too. More about this, see the discussion here in SO.

In the new runtime (i.e. 64 bit on Mac, or iPhone OS, or iPhone simulator starting the ones coming with XCode 4) you don't even have to declare a backing instance variable explicitly; an ivar is created by the compiler when you @synthesize it, and you can't access that ivar directly. Thus, if you are OK with supporting only those platforms, that's the best approach.

Yuji
You can access the synthesized iVars directly which, imho, makes using them ripe for misuse.
kubi