Google 的 Objective-C 代碼規范指南
注意事項
顯示在本指南中的隱藏細節
這個風格指南包含很多最初不可見的細節。它們被標記為三角形圖標，你可以在左邊看到。現在點擊它，你應該會看到“萬歲”出現在下面。
背景
Objective-C是一種很動態的、面向對象的C語言擴展。它被設計成易用易讀，同時支持復雜的面向對象設計。它是Mac OS X和iPhone上開發新應用的主要開發語言
Cocoa是在Mac OS X平臺上的一個主要的應用框架。這是一個提供給全功能Mac OS X應用程序的快速開發的Objective-C類集合。
Apple已經為Objective-C編寫了一本很好的、被廣泛接受的編碼指南；Google也為C++寫了一本類似的指南。這本Objective-C指南意在成為一個對Apple和Google的一般建議的自然組合。因此，在讀這本指南之前，確定你已經度過：
- Apple的Cocoa編碼指南
- Google的開源C++設計指南 </ul>
注意：所有在Google C++指南中禁用的在Objective-C++里也一樣，除非本文特別指出。
這個文檔是為了描述用于所有Mac OS X代碼中的Objective-C（和Objective-C++）編碼指南和實踐的。這些指南的很多地方已經進化并在其他項目和團隊已經過時。谷歌開發的開源項目符合本指南中的要求。
谷歌已經發布了符合這些準則的，作為Mac項目的谷歌工具箱（以下簡稱GTM）的一部分的開源代碼。意味著要在不同項目共享的代碼是一個包含在這個庫中很好的候選。
注意：這本指南不是一個Objective-C教程。我們假設讀者對這么語言很熟悉。如果你是一個Objective-C初學者或需要復習，請閱讀的Objective-C編程語言這本書。
例子
他們說一個例子勝過千言萬語，讓我們開始用一個例子讓你感受Objective-C的風格，間距，命名等。
一個頭文件的例子，展示了@interface聲明的正確注釋和間距：
#import <Foundation/Foundation.h>// A sample class demonstrating good Objective-C style. All interfaces, // categories, and protocols (read: all top-level declarations in a header) // MUST be commented. Comments must also be adjacent to the object they're // documenting. // // (no blank line between this comment and the interface) @interface Foo : NSObject { @private NSString _bar; NSString _bam; }
// Returns an autoreleased instance of Foo. See -initWithBar: for details // about |bar|.
- (id)fooWithBar:(NSString *)bar;
// Designated initializer. |bar| is a thing that represents a thing that // does a thing.
- (id)initWithBar:(NSString *)bar;
// Gets and sets |_bar|.
- (NSString *)bar;
- (void)setBar:(NSString *)bar;
// Does some work with |blah| and returns YES if the work was completed // successfully, and NO otherwise.
- (BOOL)doWorkWithBlah:(NSString *)blah;
@end</pre>一個源文件的例子，展示了一個接口的@implementation的正確注釋和間距。它也包含一些重要方法，像getters、setters、init和dealloc的參考實現：
#import "Foo.h"@implementation Foo
- (id)fooWithBar:(NSString *)bar { return [[[self alloc] initWithBar:bar] autorelease]; }
// Must always override super's designated initializer.
(id)init { return [self initWithBar:nil]; }
(id)initWithBar:(NSString *)bar { if ((self = [super init])) { _bar = [bar copy]; _bam = [[NSString alloc] initWithFormat:@"hi %d", 3]; } return self; }
(void)dealloc { [_bar release]; [_bam release]; [super dealloc]; }
(NSString *)bar { return _bar; }
(void)setBar:(NSString *)bar { [_bar autorelease]; _bar = [bar copy]; }
(BOOL)doWorkWithBlah:(NSString *)blah { // ... return NO; }
@end</pre>在@interface、@implementation和@end前后的空行是可選的。如果你的@interface聲明了實參，那么右括號之后需要有一個空行。
除非interface或implementation很短，比如，當定義一小部分私有方法或一個橋接類時，添加空行通常有利于可讀性。
間距和格式
Exceptions
?在單獨一行時，使用 @ 標簽格式化 exceptions，@ 標簽和開放括號 ({) 間加一個空格，在@catch 和 對象捕獲聲明之間也是。
Protocols
?在類型標識符和封裝在尖括號中的 Protocols 名稱之間不應該有空格。
Blocks
?Blocks 在創建回調函數時更傾向于目標選擇器模式，這可以讓代碼更易讀。塊內的代碼應縮進4個空格。
命名
命名規則對于代碼的可維護性是非常重要的。Objective-C的方法命名趨向于超長命名，但這會帶來良好的代碼閱讀感受，就像讀散文一樣，同時還避免了很多不必要的注釋。
在撰寫純粹的Objective-C代碼時，我們主要是遵循標準的Objective-C命名規范。這些命名方針可能和C++的命名規范相去甚遠。比如，Google的C++規范中推薦在變量名中的單詞間使用下劃線，而Objective-C的規范推薦使用駝峰命名法，這也是在Objective-C社區中的標準做法。
任何類、目錄、方法或者變量的名字都應該將其中的首字母縮略詞設為大寫。下面是蘋果官方使用的大寫的首字母縮略詞：URL，TIFF和EXIF。
然而，在編寫Objective-C++代碼時，往往并非能完全按照規范來進行。很多項目會使用Objective-C，或是Cocoa，或是C++后端與原生的Cocoa前端通信的方式來實現跨平臺的C++ API。這就導致了兩種語言規范直接沖突的情況。我們的解決方法是依據方法/函數具體實現的方式來決定命名。如果你在一個@implementationblock里面，就使用Objective-C的命名規范。如果你在一個C++類里面實現一個方法，就使用C++命名規范。這就避免了在一個函數中實例變量和本地變量的命名規則混合使用的情況，減少了對代碼的可閱讀性造成的極大損害。
文件名
?文件名應該反映其中包含的類實現的名稱，按照你項目中的約定且大小寫相關。
Objective-C++
?在一個源碼文件中， Objective-C++ 遵循你實現的函數/方法的風格。
類名
?類名（類別和協議名稱）應為大寫，并開始使用大小寫混合以區分單詞。
分類名稱
?分類名稱應該以一個2到3個字母的前綴開始，識別分類是項目的一部分，還是打開使用。分類，名稱應該結合它擴展的類的名稱。
Objective-C 方法名稱
?方法名稱應該以小寫字母開頭，混合大小寫。每個命名參數也應該以小寫字母開頭。
變量名
?變量名以小寫字母開頭，混合大小寫以區分單詞。實例變量以下劃線開頭。例如：myLocalVariable，_myInstanceVariable。
注釋
盡管寫的時候很痛苦，但是他們對于保持你代碼的可讀性來說絕對是至關重要的。下面幾條規則描述了你應該什么時候在什么地方加注釋。但是要記住，雖然注釋很重要，但是最好的代碼都是自注釋的。給變量和類型一個有意義的名字，要比用一個難懂的名字然后再費力的用注釋來解釋好得多。
寫注釋的時候，要寫給你的讀者：下一個要讀懂你代碼的貢獻者。多寫點吧——下個沒準就是你自己！
記住所有c++編程規范里列出的規則和協定在這里也是生效的，下面是幾點補充。
File Comments文件注釋
?被申明在頭文件的變量必須是私有的
當變量被申明在頭文件時，這個變量必須被標記為@private
標識初始化器
要描述或者標識好初始化器
重寫初始化器
當你寫一個包含init()方法的的子類時，一定要確定重寫了父類的初始化器
重寫NSObject方法的位置
強連建議將重寫NSObject的方法放到@implementation注記的上面
初始化
不要在init方法中把變量初始化為0或者nil，這樣做完全是多余的
避免處理new方法
不要嘗試調用NSObject類的new()方法，也不要在他的子類中復寫這個方法。我們可以利用他的init方法來實例化這些保留對象
保持公有API簡單
要保持你的類盡量簡單：避免過分渲染APIs.如果有的方法沒必要公開，那就不要公開.要利用private去避免把公有頭弄得雜亂
#import 和 #include
要引入Objective-C/Object-C++頭文件時用#import;要引入C/C++頭文件時用#include.
利用跟框架
在獨立文件之上應該包含跟框架
創建完了即可銷毀釋放
當創建一些臨時對象時，在創建的那一行銷毀并釋放比在同一個方法內下創建然后過一會兒銷毀更好
釋放并保留
對象的業務遵循釋放并保持規則
在執行init或者dealloc方法時避免訪問器
當init和dealloc方法正在執行時，子類的實例化可能處在一個不穩定的狀態，所以在這些方法中的代碼盡量避免調用其他訪問器
屬性
?在下列情況下請注意，直接使用@property注解是被允許的：屬性是將會限制你代碼允許在iPhone和Mac OS X 10.5(雪豹)以上版本的Objective-C 2.0的特性。點符號只有聲明@property才允許被訪問。
沒有示例變量的接口
?接口中除了空大括號之外，請不要聲明任何實例變量。
自動合成實例變量
?使用自動合成實例變量是被允許的。編寫的代碼必須支持更早之前的編譯工具鏈版本（Xcode 4.3或更早的版本亦或GCC編譯）或者應該直接使用@synthesize注解調用從協議中繼承來的屬性。
自動引用計數（ARC）
?由于項目使用的是Xcode 4.2或更高版本，并將只運行在64位版Mac OS X 10.7 和 iOS 5.0及更高版本中，ARC 是優先的。手動引用計數在支持早期環境中的歸零弱指針時將不可用。
需要 ARC 的類應該包含一個預處理指令來防止編譯使用手動引用計數。
象 __unsafe _unretained 和 __weak 的所有權限定符應該在變量名的前面。沒必要為變量指定 __strong，因為它是默認的。另一方面，屬性應該始終指定 strong 關鍵字而不是依賴于編譯器的默認值。
被編譯的文件使用 ARC 時需要有預處理指令以防止編譯沒有 ARC。請參見下方的代碼片段以了解詳情。
NSNumber字面值
?對于利用Xcode4.4或以上版本創建的C語言項目來說，運用NSNumber字面值是被允許的。然而使用這種做法將會限制你代碼對于其他工具鏈的可移植性。
Cocoa模式
委派模式
?委派對象不應該被保留。
模型、視圖、控制器
?將模型從視圖中分離。將控制器從視圖和模型中分離。使用@protocols注解回調APIs。
歷史說明
后綴下劃線 vs 前置下劃線
?后綴下劃線曾經用于表示示例變量的名稱。