此文轉(zhuǎn)載于：http://blog.xcodev.com/archives/objective-c-naming/
備注：命名規(guī)范還可以參考 Effective Objective-C 2.0 一書。
There are only two hard things in Computer Science: cache > invalidation and naming things.在計(jì)算機(jī)科學(xué)中只有兩件難事：> 緩存失效和命名。
— Phil Karlton
計(jì)算機(jī)語言是人和計(jì)算機(jī)之間通訊的媒介。好的代碼應(yīng)該是就像人對計(jì)算機(jī)說話那樣，自然而優(yōu)雅。命名看上去是一件很簡單的事，而往往越是簡單的事越難做好，否則大師們也不會把命名看成是計(jì)算機(jī)界的難題了。如何把Objective-C這門計(jì)算機(jī)語言以優(yōu)雅的方式“說”出，還是比較考驗(yàn)工程師對它的理解深度的。在蘋果的SDK中有大量的API，我們可以從這些API中體會到一些命名的藝術(shù)。
減少縮寫
- 命名縮寫只用于通用專業(yè)術(shù)語，如URL
- 不可自創(chuàng)命名縮寫，如Ctr、Msg
- 命名寧可長一些，也不要難于理解。
是否在看別人代碼時(shí)各種縮寫而不知其所以然？簡短的名字確實(shí)比較好，但不可濫用縮寫導(dǎo)致失去可讀性。
過程化
- 動作發(fā)生之前用Will
- 發(fā)生之后用Did
- 詢問是否發(fā)生用Should
每個(gè)處理都是有一定過程的，這個(gè)處理往往會產(chǎn)生一些通知和回調(diào)，好的命名必須要明確當(dāng)前過程中的步驟。命名這些通知和回調(diào)時(shí)最好提供發(fā)生前后兩個(gè)版本，如果發(fā)生前要回調(diào)確認(rèn)，請用Should
命名該回調(diào)，并返回一個(gè)BOOL值。
名字空間
各種全局作用范圍的函數(shù)，常量，類，枚舉，結(jié)構(gòu)等命名必須加命名前綴。
Objective-C中沒有C++那樣的名字空間概念，也沒有Java包名的概念，隨著工程代碼的增加，難免會出現(xiàn)名字沖突，因此全局作用范圍的名字必須唯一。比較經(jīng)典的做法就是加命名前綴。大多數(shù)人認(rèn)為命名前綴只是在類的前面加幾個(gè)大寫字母，其實(shí)不僅僅如此。
類型(類、枚舉、結(jié)構(gòu))命名前要加相關(guān)模塊前綴。
UIViewNSStringCGRect常量命名要加相關(guān)類型名前綴。
UIApplicationDidFinishLaunchingNotificationCGRectZero函數(shù)命名要加相關(guān)類型名前綴。
CGRectMakeCGPointMake枚舉類型命名要加相關(guān)類名前綴，并且枚舉值命名要加枚舉類型前綴。
typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {
UIViewAnimationTransitionNone,
UIViewAnimationTransitionFlipFromLeft,
UIViewAnimationTransitionFlipFromRight,
UIViewAnimationTransitionCurlUp,
UIViewAnimationTransitionCurlDown,
};
做到以上幾點(diǎn)幾乎可以做到名字不會沖突。
參數(shù)提示
方法命名時(shí)，每個(gè)參數(shù)前要加參數(shù)的名稱提示。
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
- (void)performSegueWithIdentifier:(NSString *)identifier sender:(id)sender
對象命名
給一個(gè)帶修飾的對象命名時(shí)要采用修飾+類型的方式，而不是先指定其類型。
很多人喜歡把對象的類型放在對象的命名前面，從而來標(biāo)識一個(gè)對象是什么類型，這很不符合Objective-C語言的特點(diǎn)，容易引起歧義，比如一個(gè)UILabel對象：
titleLabel //表示標(biāo)題的label，是UIlabel對象
labelTitle //label的標(biāo)題？似乎是一個(gè)NSString？
confirmButton //確認(rèn)按鈕
buttonConfirm //不自然的命名，看上去像是按鈕點(diǎn)擊動作。
方法命名符合語法
大部分方法可以分成下面兩類，而這兩類往往被亂用。它們是：
要什么
做什么
“要什么”表示取得某個(gè)對象，要以名詞作為方法的開頭；“做什么”表示執(zhí)行某種操作，要以動詞作為方法開頭。看看下面這個(gè)命名方式：
- (XXItem *)itemNamed:(NSString *)name //Good. 意思清晰
- (XXItem *)findItemWithName:(NSString *)name //更像是一種操作，而不是返回一個(gè)對象。
findItemWithName這個(gè)命名表示一種操作，而無需返回對象，比如它可以用于設(shè)置類的內(nèi)部成員，比如：
- (void)findItemWithName:(NSString *)name{ ... self.foundItem = xxx; ... }
get
“要什么”往往被胡亂命名為get開頭的方法。首先get是一個(gè)動詞，所以它還是“做什么”或者說“做的是要什么”。那么get方法不要用于返回對象，但它可用于參數(shù)中返回。
- (XXItem *)getItemAtIndex:(NSUInteger)index //Bad!! 不規(guī)范的命名
- (XXItem *)itemAtIndex:(NSUInteger)index //Good, 命名清晰
- (void)getItem:(XXItem **)outItem atIndex:(NSUInteger)index //比較符合規(guī)范，但第二種更好。
可知性
回調(diào)時(shí)被調(diào)用者要知道其調(diào)用者
可以在回調(diào)方法中第一個(gè)參數(shù)中加上調(diào)用者：
- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions
- (void)buttonTapped:(UIButton*)sender
常量還是宏
全局常量不可使用宏定義
我們經(jīng)常看到一些用宏定義的通知，關(guān)鍵字等。其實(shí)這么做是非常危險(xiǎn)的，因?yàn)楹旰芸赡鼙恢囟x，而且引用不同的文件可能會導(dǎo)致宏的不同，所以盡量使用const來定義常量。
一些思考
命名的好壞在開發(fā)中往往也不怎么重視，畢竟差的命名也不會影響程序邏輯。但是不好的命名在大項(xiàng)目中帶來的隱形維護(hù)成本是相當(dāng)高的，這些在項(xiàng)目開始時(shí)可能還很難察覺，而后來會陷入前仆后繼的維護(hù)困境中。我們往往非常重視項(xiàng)目邏輯的復(fù)雜性，卻不能好好的把“簡單”的命名做好。其實(shí)，如果簡單的東西都做不好，那么做出再復(fù)雜的東西那也是垃圾。
