StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6112553
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
5
CommunityOwnedDate
2012-08-21T21:08:28.107
CreationDate
2011-05-24T15:02:31.090
FavoriteCount
0
LastActivityDate
2015-06-16T16:34:10.580
LastEditDate
2017-05-23T12:05:58.687
LastEditorUserId
-1
OwnerUserId
412916
ParentId
6112283
PostTypeId
2
Score
27
ViewCount
0
LastEditorDisplayName
text
Body
A leading underscore is a naming convention helpful to differentiate between instance variables and accessors. For the compiler it is just a common ivar rename. Consider the difference (non ARC code): <pre><code>self.date = [NSDate date]; // OK, the setter releases the old value first date = [NSDate date]; // WRONG, skipping the setter causes a memory leak _date = [NSDate date]; // WRONG but easier to see it's not a local variable </code></pre> With ARC variables won't be leaked, but it is still wrong to skip the @property attributes: <pre><code>@property (copy) string; // ... self.string = someString; // OK, string is copied string = someString; // WRONG string is retained but not copied _string = someString; // WRONG but hopefully easier to see </code></pre> Even worst, some APIs like Core Data rely on KVC notifications to perform lazy loading. If you accidentally skip the accessors, your data will come back as nil. This is the reason you often find <code>@synthesize var=_var</code>, which makes <ul> <li><code>self.var</code> an accessor reference (invoking setters and getters), </li> <li><code>_var</code> a direct access reference (skipping setters and getters), </li> <li>and <code>var</code> an invalid reference. </li> </ul> Given that <code>@synthesize var=_var</code> is autogenerated by LLVM 4.0 when <code>@synthesize</code> is omitted, you can consider this the default naming convention in Objective-C. Keep reading for details... <hr> <h2>Modern runtime</h2> In Objective-C 2.0 you declare variables like this: <pre><code>@interface User : NSObject @property (nonatomic, assign) NSInteger age; @end @implementation User { @synthesize age; // this line can be omitted since LLVM 4.0 @end </code></pre> which is translated by the compiler as follows: <pre><code>@interface User : NSObject { NSInteger age; } @end @implementation User -(void)setAge:(NSInteger)newAge { age=newAge; } -(void)age { return age; } @end </code></pre> If you prefer to use the underscore convention just add the following: <pre><code>@synthesize age=_age; </code></pre> That's all you need because <a href="http://developer.apple.com/library/mac/documentation/cocoa/conceptual/objectivec/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW3" rel="nofollow noreferrer">with the modern runtime</a>, if you do not provide an instance variable, the compiler adds one for you. Here is the code that gets compiled: <pre><code>@interface User : NSObject { NSInteger _age; } @end @implementation User -(void)setAge:(NSInteger)newAge { _age=newAge; } -(void)age { return _age; } @end </code></pre> What happens if you add both the ivar and the @property? If the variable has the same name and type, the compiler uses it instead generating a new variable. Quoting The Objective-C Programming Language > Declared Properties > <a href="http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW9" rel="nofollow noreferrer">Property Implementation Directives</a>: <blockquote> There are differences in the behavior of accessor synthesis that depend on the runtime: <ul> <li>For the modern runtimes, instance variables are synthesized as needed. If an instance variable of the same name already exists, it is used.</li> <li>For the legacy runtimes, instance variables must already be declared in the @interface block of the current class. If an instance variable of the same name as the property exists, and if its type is compatible with the property’s type, it is used —otherwise, you get a compiler error.</li> </ul> </blockquote> <h2>Legacy runtime</h2> But if you need to <a href="http://developer.apple.com/library/mac/documentation/cocoa/conceptual/objectivec/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW3" rel="nofollow noreferrer">support the legacy runtime</a> you must either provide an instance variable with the same name and compatible type of the property or specify another existing instance variable in the @synthesize statement. So the legacy code without underscores would be: <pre><code>@interface User : NSObject { NSInteger age; } @property (nonatomic, assign) NSInteger age; @end @implementation User @synthesize age; @end </code></pre> Or if you prefer the underscore convention: <pre><code>@interface User : NSObject { NSInteger _age; } @property (nonatomic, assign) NSInteger age; @end @implementation User @synthesize age = _age; @end </code></pre> <h2>What is the best way?</h2> Apple discourages the use of underscore in methods, but not on variables!. Apple on methods: <a href="http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingBasics.html#//apple_ref/doc/uid/20001281-1002931-BBCFHEAB" rel="nofollow noreferrer">Coding Guidelines for Cocoa: Typographic Conventions</a>: <blockquote> Avoid the use of the underscore character as a prefix meaning private, especially in methods. Apple reserves the use of this convention. Use by third parties could result in name-space collisions; they might unwittingly override an existing private method with one of their own, with disastrous consequences. </blockquote> Apple on variables: <a href="https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-1001757" rel="nofollow noreferrer">Declared Properties and Instance Variables</a> <blockquote> Make sure the name of the instance variable concisely describes the attribute stored. Usually, you should not access instance variables directly, instead you should use accessor methods (you do access instance variables directly in init and dealloc methods). To help to signal this, prefix instance variable names with an underscore (_), for example: <code>@implementation MyClass { BOOL _showsTitle; }</code> </blockquote> <a href="http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf" rel="nofollow noreferrer">ISO/IEC 9899 7.1.3 Reserved identifiers</a> (aka C99): <blockquote> <ul> <li>All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. </li> <li>All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.</li> </ul> </blockquote> On top of that, double leading underscore is traditionally reserved for the vendor of the preprocessor / compiler / library. This avoids the case where you use <code>__block</code> somewhere in your code, and Apple introduces that as a new non-standard keyword. <a href="http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml" rel="nofollow noreferrer">Google Objective-C Style guide</a>: <blockquote> Variable Names Variables names start with a lowercase and use mixed case to delimit words. Class member variables have trailing underscores. For example: myLocalVariable, myInstanceVariable_. Members used for KVO/KVC bindings may begin with a leading underscore iff use of Objective-C 2.0's @property isn't allowed. </blockquote> Google's trailing underscore doesn't force you to type one more character before Xcode fires the autocomplete, but you'll realize it is an instance variable slower if the underscore is a suffix. Leading underscore is also discouraged in C++ (see <a href="https://stackoverflow.com/questions/228783/">What are the rules about using an underscore in a C++ identifier?</a>) and Core Data properties (try adding a leading underscore in the model and you'll get "Name must begin with a letter"). Whatever you chose, collisions are unlikely to happen, and if they do, you'll get a warning from the compiler. When in doubt, use the default LLVM way: <code>@synthesize var=_var;</code> <hr> I own an edit of this post to reading <a href="https://www.bignerdranch.com/blog/a-motivation-for-ivar-decorations/" rel="nofollow noreferrer">A Motivation for ivar decorations</a> by Mark Dalrymple. You may want to check it out.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POQuestion about @synthesize
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USJano
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POQuestion about @synthesize
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTDownMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.