[[118230]]

There are only two hard things in Computer Science: cache invalidation and naming things.

在計算機科學中只有兩件難事：緩存失效和命名。

— Phil Karlton

計算機語言是人和計算機之間通訊的媒介。好的代碼應該是就像人對計算機說話那樣，自然而優(yōu)雅。命名看上去是一件很簡單的事，而往往越是簡單的事越難做好，否則大師們也不會把命名看成是計算機界的難題了。如何把Objective-C這門計算機語言以優(yōu)雅的方式“說”出，還是比較考驗工程師對它的理解深度的。在蘋果的SDK中有大量的API，我們可以從這些API中體會到一些命名的藝術(shù)。

減少縮寫

命名縮寫只用于通用專業(yè)術(shù)語，如 URL，不可自創(chuàng)命名縮寫，如 Ctr、Msg。命名寧可長一些，也不要難于理解。

是否在看別人代碼時各種縮寫而不知其所以然？簡短的名字確實比較好，但不可濫用縮寫導致失去可讀性。

過程化

動作發(fā)生之前用 Will，發(fā)生之后用 Did，詢問是否發(fā)生用 Should。

每個處理都是有一定過程的，這個處理往往會產(chǎn)生一些通知和回調(diào)，好的命名必須要明確當前過程中的步驟。命名這些通知和回調(diào)時***提供發(fā)生前后兩個版本，如果發(fā)生前要回調(diào)確認，請用 Should 命名該回調(diào)，并返回一個 BOOL 值。

名字空間

各種全局作用范圍的函數(shù)，常量，類，枚舉，結(jié)構(gòu)等命名必須加命名前綴。

Objective-C中沒有C++那樣的名字空間概念，也沒有Java包名的概念，隨著工程代碼的增加，難免會出現(xiàn)名字沖突，因此全局作用范圍的名字必須唯一。比較經(jīng)典的做法就是加命名前綴。大多數(shù)人認為命名前綴只是在類的前面加幾個大寫字母，其實不僅僅如此。

•類型(類、枚舉、結(jié)構(gòu))命名前要加相關(guān)模塊前綴

UIView  
NSString  
CGRect  

 •常量命名要加相關(guān)類型名前綴。

UIApplicationDidFinishLaunchingNotification  
CGRectZero  

•函數(shù)命名要加相關(guān)類型名前綴。

CGRectMake  
CGPointMake  

 •枚舉類型命名要加相關(guān)類名前綴，并且枚舉值命名要加枚舉類型前綴。

typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {  
    UIViewAnimationTransitionNone,  
    UIViewAnimationTransitionFlipFromLeft,  
    UIViewAnimationTransitionFlipFromRight,  
    UIViewAnimationTransitionCurlUp,  
    UIViewAnimationTransitionCurlDown,  
};  

做到以上幾點幾乎可以做到名字不會沖突。

參數(shù)提示

方法命名時，每個參數(shù)前要加參數(shù)的名稱提示。

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil  
- (void)performSegueWithIdentifier:(NSString *)identifier sender:(id)sender  

對象命名

給一個帶修飾的對象命名時要采用修飾+類型的方式，而不是先指定其類型。

很多人喜歡把對象的類型放在對象的命名前面，從而來標識一個對象是什么類型，這很不符合Objective-C語言的特點，容易引起歧義，比如一個 UILabel 對象：

titleLabel      //表示標題的label，是UIlabel對象  
labelTitle      //label的標題？似乎是一個NSString？  
  
confirmButton   //確認按鈕  
buttonConfirm   //不自然的命名，看上去像是按鈕點擊動作。  

方法命名符合語法

大部分方法可以分成下面兩類，而這兩類往往被亂用。它們是：

•要什么

•做什么

“要什么”表示取得某個對象，要以名詞作為方法的開頭；“做什么”表示執(zhí)行某種操作，要以動詞作為方法開頭。看看下面這個命名方式：

- (XXItem *)itemNamed:(NSString *)name           //Good. 意思清晰  
- (XXItem *)findItemWithName:(NSString *)name    //更像是一種操作，而不是返回一個對象。 

findItemWithName 這個命名表示一種操作，而無需返回對象，比如它可以用于設置類的內(nèi)部成員，比如：

- (void)findItemWithName:(NSString *)name{  
    ...  
    self.foundItem = xxx;  
    ...  
}  

get

“要什么”往往被胡亂命名為get開頭的方法。首先get是一個動詞，所以它還是“做什么”或者說“做的是要什么”。那么get方法不要用于返回對象，但它可用于參數(shù)中返回。

- (XXItem *)getItemAtIndex:(NSUInteger)index                  //Bad!! 不規(guī)范的命名  
- (XXItem *)itemAtIndex:(NSUInteger)index                     //Good, 命名清晰  
- (void)getItem:(XXItem **)outItem atIndex:(NSUInteger)index  //比較符合規(guī)范，但第二種更好。  

可知性

回調(diào)時被調(diào)用者要知道其調(diào)用者

可以在回調(diào)方法中***個參數(shù)中加上調(diào)用者：

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions  
- (void)buttonTapped:(UIButton*)sender  

常量還是宏

全局常量不可使用宏定義

我們經(jīng)?？吹揭恍┯煤甓x的通知，關(guān)鍵字等。其實這么做是非常危險的，因為宏很可能被重定義，而且引用不同的文件可能會導致宏的不同，所以盡量使用const來定義常量。

一些思考

命名的好壞在開發(fā)中往往也不怎么重視，畢竟差的命名也不會影響程序邏輯。但是不好的命名在大項目中帶來的隱形維護成本是相當高的，這些在項目開 始時可能還很難察覺，而后來會陷入前仆后繼的維護困境中。我們往往非常重視項目邏輯的復雜性，卻不能好好的把“簡單”的命名做好。其實，如果簡單的東西都 做不好，那么做出再復雜的東西那也是垃圾。