看了《禪與 Objective-C 編程藝術》，發現不少平時不注意的或注意但沒有系統總結的東西，特此記錄一下。

這次沒有整理完，后續更新會結合手里的一些其他資料整理。

新博客wossoneri.com傳送門

完整的介紹看這兩個鏈接
Google開源項目風格指南
禪與 Objective-C 編程藝術 （Zen and the Art of the Objective-C Craftsmanship 中文翻譯）

本文的意義就是找出一些我自己平時不注意的知識點進行總結，同時提出一些自己的觀點，然后自己沒事看看總結，提高編碼質量。

條件語句

條件語句體應該總是被大括號包圍。

我經常為了讓代碼看起來干凈一些，所以對于條件語句體內只有一行代碼的時候，我就會省去大括號以減少代碼行數。
像這樣：

if (!error)return success; //or if (!error) return success;

這樣寫很容易帶來隱患，比如增加一行代碼時，就容易對這行代碼是在語句體內還是外產生誤解導致錯誤。注釋一行代碼容易使后面一行代碼成為語句體內的內容。

所以老老實實把代碼寫規范了：

if (!error) {return success; }

尤達表達式

星球大戰中尤達大師的講話方式，總是用倒裝的語序

文章不建議使用尤達表達式，即不要使用常量和變量比較的方式。

比如：

if (5 == count) { ... //or if ([@42 isEqual:myValue]) { ...

建議寫成：

if (count == 5) { ... //or if ([myValue isEqual:@42]) { ...

對于這一點，我有一些異議。因為對于第一種寫法，寫成5 == count可以避免把==寫成=，如果按照不用尤達的寫法，當我把比較寫成賦值時count = 5，編譯器是無法檢測出我的失誤的，而且對于這類失誤，自己debug的時候也很難發現。而對于第二種寫法使用isEqual方法就不存在這種問題。

所以這一點見仁見智吧。面對if (5 == count)這類條件語句，我還是偏向用尤達表達式的。

nil 和 BOOL 的檢查

因為 nil 是 解釋到 NO，所以沒必要在條件語句里面把它和其他值比較。同時，不要直接把它和 YES 比較，因為 YES 的定義是 1， 而 BOOL 是 8 bit的，實際上是 char 類型。

這一點很重要，不要在條件語句內出現YES或者NO，多使用非運算符。

不推薦：

if (someObject == YES) { ... // Wrong if (myRawValue == YES) { ... // Never do this. if ([someObject boolValue] == NO) { ...

推薦：

if (someObject) { ... if (![someObject boolValue]) { ... if (!someObject) { ...

黃金大道

在使用條件語句編程時，代碼的左邊距應該是一條“黃金”或者“快樂”的大道。

也就是說，不要嵌套 if 語句。使用多個 return 可以避免增加循環的復雜度，并提高代碼的可讀性。

這一點我深有感觸，在以往編碼的時候，我都很耿直的把一些方法寫到嵌套分支里。這樣寫的容易，但改代碼邏輯的時候就麻煩了。

比如：

- (void)someMethod {if ([someOther boolValue]) {//Do something important// blablabla ...} }

這種情況下，一個是代碼看起來很復雜，另一個是改邏輯的時候，blablabla的內容都要拷貝出來，放在新修改的邏輯中去。

所以直到有一次思考優化代碼的時候，我才想起來用相反的邏輯去處理它，即使用 return。比如：

- (void)someMethod {if (![someOther boolValue]) {return;}//Do something important }

把邏輯判斷單獨擇出來，處理代碼就直接放在函數里。不符合邏輯的 return 掉，符合邏輯的直接就會運行到處理代碼處。而且這樣寫代碼層次很清晰。

Case 語句

除非編譯器強制要求，括號在 case 語句里面是不必要的。但是當一個 case 包含了多行語句的時候，需要加上括號。

個人經驗，好像在 case 中創建實例的時候，編譯器會提醒你要為這個 case 加上括號。

switch (condition) {case 1:// ...break;case 2: {// ...// Multi-line example using bracesbreak;}case 3:// ...break;default:// ...break; }

常量使用、枚舉和命名規范

見這篇博客：Objective-C 常量和枚舉

方法

方法名與方法類型 (-/+ 符號)之間應該以空格間隔。方法段之間也應該以空格間隔（以符合 Apple 風格）。參數前應該總是有一個描述性的關鍵詞。

這里要注意的一點是盡量少用 and 這個詞。我因為入門的時候看的書經常用 and ，感覺這樣閱讀起來比較連貫，所以也養成了寫 and 的習慣。后來感覺加 and 的確不是很好。關于看書命名這一塊推薦看一下 Swift 的函數命名，因為 Swift 設計的時候一部分考慮到了 OC 當前的設計思想，同時對舊設計思想有了一些優化。看完你就會有自己的一套理解了。

不推薦寫法：

- (void)setT:(NSString *)text i:(UIImage *)image; - (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag; - (id)taggedView:(NSInteger)tag; - (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height; - (instancetype)initWith:(int)width and:(int)height; // Never do this.

推薦寫法：

- (void)setExampleText:(NSString *)text image:(UIImage *)image; - (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag; - (id)viewWithTag:(NSInteger)tag; - (instancetype)initWithWidth:(CGFloat)width height:(CGFloat)height;

美化代碼

空格

• 縮進使用 4 個空格。 永遠不要使用 tab。可以在 Xcode 中設置按 tab 插入 4 個空格。
• 方法的大括號和其他的大括號(if/else/switch/while 等) 總是在同一行開始，在新起一行結束。

第一點就不說了，前段時間看文章說還有人用 3 個空格，8 個空格的。個人還是覺得 4 空格比較舒服。

第二點是要注意的，可能以前看的初級書都是這樣寫：

if (user.isHappy) {//Do something } else {//Do something else }

但分開寫的話代碼層次關系會更明顯：

if (user.isHappy) {//Do something } else {//Do something else }

• 方法之間應該要有一個空行來幫助代碼看起來清晰且有組織。 方法內的空格應該用來分離功能，但是通常不同的功能應該用新的方法來定義。
• 優先使用 auto-synthesis。但是如果必要的話， @synthesize and @dynamic
• 在實現文件中的聲明應該新起一行。
• 應該總是讓冒號對齊。有一些方法簽名可能超過三個冒號，用冒號對齊可以讓代碼更具有可讀性。即使有代碼塊存在，也應該用冒號對齊方法。

這幾點 Xcode 會幫你做一部分，比如說冒號對齊在 Xcode 里就是自動的。但還是注意一下吧。

不推薦：

[UIView animateWithDuration:1.0 animations:^{// something } completion:^(BOOL finished) {// something }];

推薦：

[UIView animateWithDuration:1.0animations:^{// something}completion:^(BOOL finished) {// something}];

換行

之前看過一個建議，就是一行代碼保持在 80 個字符。
后來在不同的 IDE 下編碼，發現不同的 IDE 在這一點上是一致的，就是可以設置一個字符長度的標志線，來提示代碼長度。默認長度都是在 80 個字符。這個 Xcode 好像是默認不開啟的，可以設置一下讓那條線顯示出來。

舉例：

self.productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:productIdentifiers];

一個像上面的長行的代碼在第二行以一個間隔（2個空格）延續

self.productsRequest = [[SKProductsRequest alloc]initWithProductIdentifiers:productIdentifiers];

括號

在以下的地方使用 Egyptian風格 括號 （譯者注：又稱 K&R 風格，代碼段括號的開始位于一行的末尾，而不是另外起一行的風格。關于為什么叫做 Egyptian Brackets，可以參考 http://blog.codinghorror.com/new-programming-jargon/ )

• 控制語句 (if-else, for, switch)

非 Egyptian 括號可以用在：

• 類的實現（如果存在)
• 方法的實現

看完就不要糾結 Java 風格 or C++ 風格了...

未完...
很多內容在整理...

轉載于:https://www.cnblogs.com/rossoneri/p/5624806.html

總結

以上是生活随笔為你收集整理的[Objective-C]编程艺术 笔记整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。