Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Most Cocoa projects use underbar as a non-<code>IBOutlet</code> instance variable prefix, and use no prefix for <code>IBOutlet</code> instance variables.</p> <p>The reason I don't use underbars for <code>IBOutlet</code> instance variables is that when a nib file is loaded, if you have a setter method for a connected outlet, that setter will be called. <em>However</em> this mechanism does <em>not</em> use Key-Value Coding, so an IBOutlet whose name is prefixed with an underbar (<em>e.g.</em> <code>_myField</code>) will <em>not</em> be set unless the setter is named exactly like the outlet (<em>e.g.</em> <code>set_myField:</code>), which is non-standard and gross.</p> <p>Also, be aware that using properties like <code>self.myProp</code> is <strong>not</strong> the same as accessing instance variables. You are <strong>sending a message</strong> when you use a property, just like if you used bracket notation like <code>[self myProp]</code>. All properties do is give you a concise syntax for specifying both the getter and setter in a single line, and allow you to synthesize their implementation; they do not actually short-circuit the message dispatch mechanism. If you want to access an instance variable directly but prefix it with <code>self</code> you need to treat <code>self</code> as a pointer, like <code>self-&gt;myProp</code> which really is a C-style field access.</p> <p>Finally, never use Hungarian notation when writing Cocoa code, and shy away from other prefixes like "f" and "m_" — that will mark the code as having been written by someone who doesn't "get it" and will cause it to be viewed by suspicion by other Cocoa developers.</p> <p>In general, follow the advice in the <a href="http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/index.html" rel="noreferrer" title="Coding Guidelines for Cocoa">Coding Guidelines for Cocoa</a> document at the <a href="http://developer.apple.com/" rel="noreferrer" title="Apple Developer Connection">Apple Developer Connection</a>, and other developers will be able to pick up and understand your code, and your code will work well with all of the Cocoa features that use runtime introspection.</p> <p>Here's what a window controller class might look like, using my conventions:</p> <pre><code>// EmployeeWindowController.h #import &lt;AppKit/NSWindowController.h&gt; @interface EmployeeWindowController : NSWindowController { @private // model object this window is presenting Employee *_employee; // outlets connected to views in the window IBOutlet NSTextField *nameField; IBOutlet NSTextField *titleField; } - (id)initWithEmployee:(Employee *)employee; @property(readwrite, retain) Employee *employee; @end // EmployeeWindowController.m #import "EmployeeWindowController.h" @implementation EmployeeWindowController @synthesize employee = _employee; - (id)initWithEmployee:(Employee *)employee { if (self = [super initWithWindowNibName:@"Employee"]) { _employee = [employee retain]; } return self; } - (void)dealloc { [_employee release]; [super dealloc]; } - (void)windowDidLoad { // populates the window's controls, not necessary if using bindings [nameField setStringValue:self.employee.name]; [titleField setStringValue:self.employee.title]; } @end </code></pre> <p>You'll see that I'm using the instance variable that references an <code>Employee</code> directly in my <code>-init</code> and <code>-dealloc</code> method, while I'm using the property in other methods. That's generally a good pattern with properties: Only ever touch the underlying instance variable for a property in initializers, in <code>-dealloc</code>, and in the getter and setter for the property.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload