看了《禪與 Objective-C 編程藝術(shù)》，發(fā)現(xiàn)不少平時(shí)不注意的或注意但沒有系統(tǒng)總結(jié)的東西，特此記錄一下。

這次沒有整理完，后續(xù)更新會(huì)結(jié)合手里的一些其他資料整理。

新博客wossoneri.com傳送門

完整的介紹看這兩個(gè)鏈接
Google開源項(xiàng)目風(fēng)格指南
禪與 Objective-C 編程藝術(shù) （Zen and the Art of the Objective-C Craftsmanship 中文翻譯）

本文的意義就是找出一些我自己平時(shí)不注意的知識(shí)點(diǎn)進(jìn)行總結(jié)，同時(shí)提出一些自己的觀點(diǎn)，然后自己沒事看看總結(jié)，提高編碼質(zhì)量。

條件語句

條件語句體應(yīng)該總是被大括號(hào)包圍。

我經(jīng)常為了讓代碼看起來干凈一些，所以對于條件語句體內(nèi)只有一行代碼的時(shí)候，我就會(huì)省去大括號(hào)以減少代碼行數(shù)。
像這樣：

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

這樣寫很容易帶來隱患，比如增加一行代碼時(shí)，就容易對這行代碼是在語句體內(nèi)還是外產(chǎn)生誤解導(dǎo)致錯(cuò)誤。注釋一行代碼容易使后面一行代碼成為語句體內(nèi)的內(nèi)容。

所以老老實(shí)實(shí)把代碼寫規(guī)范了：

if (!error) {return success; }

尤達(dá)表達(dá)式

星球大戰(zhàn)中尤達(dá)大師的講話方式，總是用倒裝的語序

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

比如：

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

建議寫成：

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

對于這一點(diǎn)，我有一些異議。因?yàn)閷τ诘谝环N寫法，寫成5 == count可以避免把==寫成=，如果按照不用尤達(dá)的寫法，當(dāng)我把比較寫成賦值時(shí)count = 5，編譯器是無法檢測出我的失誤的，而且對于這類失誤，自己debug的時(shí)候也很難發(fā)現(xiàn)。而對于第二種寫法使用isEqual方法就不存在這種問題。

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

nil 和 BOOL 的檢查

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

這一點(diǎn)很重要，不要在條件語句內(nèi)出現(xiàn)YES或者NO，多使用非運(yùn)算符。

不推薦：

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

推薦：

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

黃金大道

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

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

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

比如：

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

這種情況下，一個(gè)是代碼看起來很復(fù)雜，另一個(gè)是改邏輯的時(shí)候，blablabla的內(nèi)容都要拷貝出來，放在新修改的邏輯中去。

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

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

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

Case 語句

除非編譯器強(qiáng)制要求，括號(hào)在 case 語句里面是不必要的。但是當(dāng)一個(gè) case 包含了多行語句的時(shí)候，需要加上括號(hào)。

個(gè)人經(jīng)驗(yàn)，好像在 case 中創(chuàng)建實(shí)例的時(shí)候，編譯器會(huì)提醒你要為這個(gè) case 加上括號(hào)。

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

常量使用、枚舉和命名規(guī)范

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

方法

方法名與方法類型 (-/+ 符號(hào))之間應(yīng)該以空格間隔。方法段之間也應(yīng)該以空格間隔（以符合 Apple 風(fēng)格）。參數(shù)前應(yīng)該總是有一個(gè)描述性的關(guān)鍵詞。

這里要注意的一點(diǎn)是盡量少用 and 這個(gè)詞。我因?yàn)槿腴T的時(shí)候看的書經(jīng)常用 and ，感覺這樣閱讀起來比較連貫，所以也養(yǎng)成了寫 and 的習(xí)慣。后來感覺加 and 的確不是很好。關(guān)于看書命名這一塊推薦看一下 Swift 的函數(shù)命名，因?yàn)?Swift 設(shè)計(jì)的時(shí)候一部分考慮到了 OC 當(dāng)前的設(shè)計(jì)思想，同時(shí)對舊設(shè)計(jì)思想有了一些優(yōu)化。看完你就會(huì)有自己的一套理解了。

不推薦寫法：

- (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;

美化代碼

空格

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

第一點(diǎn)就不說了，前段時(shí)間看文章說還有人用 3 個(gè)空格，8 個(gè)空格的。個(gè)人還是覺得 4 空格比較舒服。

第二點(diǎn)是要注意的，可能以前看的初級(jí)書都是這樣寫：

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

但分開寫的話代碼層次關(guān)系會(huì)更明顯：

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

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

這幾點(diǎn) Xcode 會(huì)幫你做一部分，比如說冒號(hào)對齊在 Xcode 里就是自動(dòng)的。但還是注意一下吧。

不推薦：

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

推薦：

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

換行

之前看過一個(gè)建議，就是一行代碼保持在 80 個(gè)字符。
后來在不同的 IDE 下編碼，發(fā)現(xiàn)不同的 IDE 在這一點(diǎn)上是一致的，就是可以設(shè)置一個(gè)字符長度的標(biāo)志線，來提示代碼長度。默認(rèn)長度都是在 80 個(gè)字符。這個(gè) Xcode 好像是默認(rèn)不開啟的，可以設(shè)置一下讓那條線顯示出來。

舉例：

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

一個(gè)像上面的長行的代碼在第二行以一個(gè)間隔（2個(gè)空格）延續(xù)

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

括號(hào)

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

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

非 Egyptian 括號(hào)可以用在：

• 類的實(shí)現(xiàn)（如果存在)
• 方法的實(shí)現(xiàn)

看完就不要糾結(jié) Java 風(fēng)格 or C++ 風(fēng)格了...

未完...
很多內(nèi)容在整理...

轉(zhuǎn)載于:https://www.cnblogs.com/rossoneri/p/5624806.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。