CODEWITHSUNDEEP
objective-ccocoa
Rudolf Adamkovič
Rudolf Adamkovič

Reputation: 31486

Prefixing private methods and properties

I use class extensions to define private methods:

@interface DFPObfuscator ()

+ (NSData *)PS_transform:(CCOperation)encryptOrDecrypt data:(NSData *)data;

@end

Using a prefix like PS_ is recommended by Apple:

... if you want to be absolutely sure that your private methods have names different from those in the superclass, you can add your own prefix to your private methods. The prefix should be as unique as possible, perhaps one based on your company or project and of the form XX_. So if your project is called Byte Flogger, the prefix might be BF_addObject:.

But what about private properties? Should I prefix them with PS_ or it's not an issue?

An example would be:

@interface MTTController ()

@property (strong, nonatomic) Class modelClass;
@property (strong, nonatomic) Class viewClass;

@end

If there's was a private property modelClass in the super-class, would it be a problem?

Upvotes: 1

Views: 271

Answers (2)

Rob Napier
Rob Napier

Reputation: 299345

Generally you do not need this advice for subclassing. If Apple creates a private method that is not prefixed with an underscore, it is a bug in their framework.

OK, I kid a little here.... It is a bug in their framework, and you should open radars against it, but they do it all the time. That said, this recommendation for prefixing private methods doesn't really work in practice this way.

First, it doesn't matter if the method is "private" or not. There's no such thing as a private method in ObjC. There are just methods that aren't declared in the header. If you declare a public method that collides with one of Apple's private methods, you'll have the same issues as if your method were private. Apple shouldn't have private methods in subclassable classes that don't have a leading underscore. Trying to avoid the cases where they do will cause premature insanity. It's not worth the trouble to worry about in most cases.

BUT! (there's always a but) There is a case where you probably should worry, which is categories. If Apple defines a category method pop on NSMutableArray, and you also define pop on NSMutableArray, then which version is run is undefined. (I give this particular example because it happened to me.) So, if you have likely names for your category methods, you should probably stick a prefix on them to protect them from Apple doing the same. As I said before, Apple shouldn't be creating private category methods without a leading underscore, but they do, so your categories may need to worry about this. Categories are also the place that you're most likely to add "common" names like "pop." So it's more likely to be a problem.

Lots of talk here. The short version is:

  • Generally speaking you don't need to prefix your methods.
  • You probably do want to prefix category methods that have very obvious names.

Note that class extensions are not categories. They're extensions of the @interface, so generally you shouldn't prefix there either. If you're synthesizing properties, and Apple has the same private property, you should get a compile error. So most of the time properties shouldn't be a problem, at least for classes that are designed to be subclassed.

I wish there were a "do this and you'll never have a problem," but the above is pretty much the real answer.

Upvotes: 1

Kalzem
Kalzem

Reputation: 7492

No problem at all ;)

But what you can do is this :

In your MTTController.m when you @synthesize myVariable; just do this instead : 

@synthesize myVariable = _myVariable;

The _ often represents the class' properties.
Or you can directly name it _myVariable in your .h

Upvotes: 0

Related Questions