Download the Corporation Unknown configuration for Accessorizer.

At a previous employer, we ran into issues where newcomers were confused by Objective-C’s memory management, especially the differences between using properties (and dot notation) and directly accessing the ivar. As you might expect, this led to many memory-related problems. I’ve long been a proponent of only using accessors to access a member unless you have a darn good reason. (And Cocoa’s ? automatic key-value observing makes it even more difficult to have a good reason not to.) In order to visibly identify accessor-vs-direct access, we instituted a naming convention to make direct access look wrong: ivars are named with an underscore prefix (“_ivar”) and properties are not. To make this even more obvious that ivars are implementation details, we declared them @private.

You may disagree with this methodology; that’s fine. But without this context, you might have a hard time understanding my configuration decisions–and why Accessorizer especially rocks in this setup.

When I first started using Accessorizer, I thought of it as a code generator, and it’s hard not to chafe at your disagreements with how code generators generate code. I’ve found that thinking of it as a code template generator makes it easier: Generate the majority of stuff you use, omit the stuff you don’t normally use, and be comfortable with the knowledge that you will regularly have to tweak its output–it’s still better than writing it from scratch every time.

Accessor Style

• “ObjC 2.0 Properties” is always turned on. Period.
• I always use the Defaults Table (more about that later).
• “Detect IBOutlets” automatically inserts the “IBOutlet” declaration into recognized subclasses. Sometimes it doesn’t identify a class I want to be an IBOutlet, but I find this to be right much more often than it is wrong.
• “Append self.view=nil” is a somewhat strangely worded option. Checking it will generate code to nil those properties identified as IBOutlets. Combined with the “-(void)viewDidUnload” checkbox to its right, it will generate a full viewDidUnload method to release your IBOutlets.
• “Assign delegates” automatically overrides your assign/retain/copy property generation setting to be “assign” for any “id” property (or others identified as a delegate form; again, I find more often right than wrong).
• I uncheck “Omit assign for scalars”. True, the “assign” is not necessary, but I find it easier to scan for “assign” when I’m code reviewing than have to think about each type and whether it is handled appropriately. (According to Apple’s documentation, “assign” is also required for garbage collection but I haven’t written any GC code yet.)
• “Assign IBOutlets” is unchecked. I guess I’m still in the “retain outlets” camp, until I bother to change my mind.
• “BOOL getter=isValue” automatically identifies a “BOOL running” property and defines the getter as “isRunning”, just as Apple recommends.

• Since I’ve primarily been coding for iOS lately, I declare my properties “nonatomic”. If/when you’re working on the desktop, you probably want “omit this”–change it or create a “desktop” configuration.
• I omit readonly/readwrite. Most of the readonly properties I create are not backed by ivars, so I find I don’t need to override this behavior often.
• I haven’t been much concerned about __weak or __strong, so I omit it. You may decide otherwise.
• “@synthesize” will create appropriate @synthesize statements when generation the Implementation. (Be sure to check “generate getter/setter”, even though it applies to @dynamic–I’ll explain later when talking about Defaults Table.)

Getter/Setter settings

Not much to say about these settings other than “Use Defaults Table”. They don’t come into play very often, since I mainly use @synthesized properties but these settings work for me when I don’t. To see the effects on generated code, temporarily switch your properties generation to @dynamic with “generate getter/setter” checked and Implementation being generated–changes will be reflected as you make them.

Dealloc

• I default to “self.property = nil” behavior; I know others disagree. If you’re one of them, simply change the option to “release” in your configuration. If you do agree, or simply want to give this way a try, make a point of removing any related KVO or NSNotification observers before these generated lines or you will receive notifications of the nil settings and you most likely don’t want that.
• “dealloc full block” is the primary reason I am not just making my configuration available without comment. If you were to just take my configuration and copy the generated code, it would break your build because I leave this deselected so it’s not in a code block. As I develop my classes, I add ivars and use Accessorizer to generate the related code. Most of the code is pretty easy to wholesale copy-n-paste, but I tend to have more logic in dealloc than Accessorizer can know about (KVO and NSNotification removal, setting delegates to nil, etc.) and I find it easier to copy this generated dealloc code into an existing method than to use this as a dealloc method and move existing behaviors into it. If you want a full dealloc method, just check the box.

Init and Undo

I’m not sure why, but I still tend to write my own init methods. Someday I’ll explore using Accessorizer for this and Undo registration more fully; until then, you’re on your own.

Defaults Table

The defaults table is used to override the “one size fits all” property generation based on the ivar’s type. I have configured every superclass of “NSMutable<Something>” to default to “copy” instead of the default “retain” in order to avoid holding reference to a mutable object when I’m expecting immutable. (This is explained in Apple’s documentation.) I don’t even use some of these classes, but when I do I don’t want to be surprised. I’m always free to edit the declaration on a case-by-case basis, but this is the behavior I want ninety-some percent of the time.

Another fun feature of the Defaults Table is the “generation” setting. If you have a class type whose behavior you tend to override often, define its generation as “dynamic”. Every time you use that class type, Accessorizer will generate an @dynamic declaration–and the accessor methods for you to use as a starting template. (This is why I check the “generate getter/setter” in the Accessor tab even though it normally won’t do anything.)

Custom Table

I don’t really use this tab, and I don’t believe any of it gets saved into a configuration set since it’s primarily for point-and-click tweaking of behavior on an ivar-by-ivar basis.

Coding Style

As I mentioned, I prefix my ivars with an underscore, so here is where I define that. By defining my ivar Prefix as “_” and Suffix as “none”, Accessorizer automatically recognizes that underscore and strips it when declaring the property. It also properly declares the backing ivar in the @synthesize directive.

• The Argument Prefix is used when generating methods like -initWith{…}. I vacillate between “a” and “none”.
• Formatting Properties: new to 2.0 is the ability to tweak whitespace in declarations more than you could in previous versions. I’m happy because now I can use my preferred “NSString* title” form; I know many others still hew to the “asterisk must bind the the variable, not type” but you’re free to change it for yourself.
• Formatting Methods: Configure the display to generate some accessor methods and experiment with these settings to see which layout you prefer. The “Tight” spacing option is actually more compressed than I like, but I find the “Spaced” option way too spread out (and I’m someone who loves whitespace). Therefore, I default to “Tight” because it’s easier to insert the few spaces I prefer than delete all the ones I don’t.
• Formatting Pragma Marks: I love me some pragma marks, but try not to go overboard with them. Feel free to experiment.
• Init Style: Apparently, “self = [super init]” is the current Apple-approved format. I’m ambivalent.

Collection Accessors, Keyed Archiving, KVO, Locking, Singleton, General and Sort

Most of these tabs are more hands-on generation of code. You need to enter a class name, and it will generate code right there–I don’t use these as frequently as accessor generation, and you can tweak the layout more directly when you do need it. At some point, I may have changed my settings from the defaults you would encounter in a new install, but I don’t really have strong suggestions for you here.