StarMirror/styleguide
1
0
Fork 0
mirror of https://github.com/google/styleguide.git synced 2024-03-22 13:11:43 +08:00
Code Issues Projects Releases Wiki Activity

Update Objective-C style guide to 2.20:

Browse Source 
- Allow dot notation for simple property access.
 - Clarify spacing around category definitions and parameters that take
   protocols.
This commit is contained in:
mmentovai 2010-08-04 17:39:00 +00:00
parent bb32401998
commit 4d50302d0e
1 changed files with 43 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
objcguide.xml
View File

@ -4,7 +4,7 @@
<p align="right"> <p align="right">
Revision 2.18 Revision 2.20
</p> </p>
@ -415,6 +415,27 @@ Revision 2.18
</BODY> </BODY>
</STYLEPOINT> </STYLEPOINT>
<STYLEPOINT title="Protocols">
<SUMMARY>
There should not be a space between the type identifier and the name
of the protocol encased in angle brackets.
</SUMMARY>
<BODY>
<p>
This applies to class declarations, instance variables, and method
delcarations. For example:
</p>
<CODE_SNIPPET>
@interface MyProtocoledClass : NSObject&lt;NSWindowDelegate&gt; {
@private
id&lt;MyFancyDelegate&gt; delegate_;
}
- (void)setDelegate:(id&lt;MyFancyDelegate&gt;)aDelegate;
@end
</CODE_SNIPPET>
</BODY>
</STYLEPOINT>
</CATEGORY> </CATEGORY>
<CATEGORY title="Naming"> <CATEGORY title="Naming">
@ -586,6 +607,10 @@ Revision 2.18
a different address-space, the method naming isn't quite as a different address-space, the method naming isn't quite as
important. important.
</p> </p>
<p>
There should be a single space between the class name and the opening
parenthesis of the category.
</p>
</BODY> </BODY>
</STYLEPOINT> </STYLEPOINT>
@ -1165,7 +1190,7 @@ Revision 2.18
Do not use the <code>NS_DURING</code>, <code>NS_HANDLER</code>, Do not use the <code>NS_DURING</code>, <code>NS_HANDLER</code>,
<code>NS_ENDHANDLER</code>, <code>NS_VALUERETURN</code> and <code>NS_ENDHANDLER</code>, <code>NS_VALUERETURN</code> and
<code>NS_VOIDRETURN</code> macros unless you are writing code that <code>NS_VOIDRETURN</code> macros unless you are writing code that
needs to run on MacOS 10.2 or before. needs to run on Mac OS X 10.2 or before.
</p> </p>
<p> <p>
Also be aware when writing Objective-C++ code that stack based objects Also be aware when writing Objective-C++ code that stack based objects
@ -1319,8 +1344,8 @@ Revision 2.18
<SUMMARY> <SUMMARY>
Properties in general are allowed with the following caveat: properties Properties in general are allowed with the following caveat: properties
are an Objective-C 2.0 feature which will limit your code to running are an Objective-C 2.0 feature which will limit your code to running
on the iPhone and MacOS X 10.5 (Leopard) and higher. Dot notation to on the iPhone and Mac OS X 10.5 (Leopard) and higher. Dot notation
access properties is not allowed. is allowed only for access to a declared <code>@property</code>.
</SUMMARY> </SUMMARY>
<BODY> <BODY>
<SUBSECTION title="Naming"> <SUBSECTION title="Naming">
@ -1446,39 +1471,20 @@ Revision 2.18
</SUBSECTION> </SUBSECTION>
<SUBSECTION title="Dot notation"> <SUBSECTION title="Dot notation">
<p> <p>
We do not allow the use of dot notation to access properties for Dot notation is idiomatic style for Objective-C 2.0. It may be used
the following reasons: when doing simple operations to get and set a <code>@property</code>
of an object, but should not be used to invoke other object behavior.
</p> </p>
<ol> <CODE_SNIPPET>
<li> NSString *oldName = myObject.name;
Dot notation is purely syntactic sugar for standard method calls, myObject.name = @"Alice";
whose readability gains are debatable. It just gives you another </CODE_SNIPPET>
way to make method calls. <BAD_CODE_SNIPPET>
</li> NSArray *array = [[NSArray arrayWithObject:@"hello"] retain];
<li>
It obscures the type that you are dereferencing. When one sees: NSUInteger numberOfItems = array.count; // not a property
<code>[foo setBar:1]</code> it is immediately clear that you are array.release; // not a property
working with an Objective-C object. When one sees </BAD_CODE_SNIPPET>
<code>foo.bar = 1</code> it is not clear if foo is an object, or
a struct/union/C++ class.
</li>
<li>
It allows you to do method calls that look like getters.
<BAD_CODE_SNIPPET>
NSString *upperCase = @"foo".uppercaseString;
</BAD_CODE_SNIPPET>
which is not only confusing, but difficult to spot in a code review.
</li>
<li>
It hides method calls.
<BAD_CODE_SNIPPET>
bar.value += 10;
</BAD_CODE_SNIPPET>
is actually two separate method calls (one to set and one to get)
and if your properties are not simple you may find a lot of work
being done in a hidden manner.
</li>
</ol>
</SUBSECTION> </SUBSECTION>
</BODY> </BODY>
</STYLEPOINT> </STYLEPOINT>
@ -1550,7 +1556,7 @@ Revision 2.18
<HR/> <HR/>
<p align="right"> <p align="right">
Revision 2.18 Revision 2.20
</p> </p>