以下是文章原文拯爽， 如有侵權(quán)請告知
條件語句
條件語句體應(yīng)該總是被大括號包圍索抓。盡管有時候你可以不使用大括號（比如，條件語句體只有一行內(nèi)容）毯炮，但是這樣做會帶來問題隱患逼肯。比如，增加一行代碼時桃煎，你可能會誤以為它是 if 語句體里面的篮幢。此外，更危險的是为迈，如果把 if 后面的那行代碼注釋掉洲拇，之后的一行代碼會成為 if 語句里的代碼。
推薦:
if (!error) {
return success;
}
不推薦:
if (!error)
return success;
和
if (!error) return success;
在 2014年2月 蘋果的 SSL/TLS 實現(xiàn)里面發(fā)現(xiàn)了知名的 goto fail 錯誤曲尸。
代碼在這里：
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
OSStatus err;
...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
...
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}
顯而易見赋续，這里有沒有括號包圍的2行連續(xù)的 goto fail; 。我們當(dāng)然不希望寫出上面的代碼導(dǎo)致錯誤另患。
此外纽乱，在其他條件語句里面也應(yīng)該按照這種風(fēng)格統(tǒng)一，這樣更便于檢查昆箕。
尤達(dá)表達(dá)式
不要使用尤達(dá)表達(dá)式鸦列。尤達(dá)表達(dá)式是指租冠，拿一個常量去和變量比較而不是拿變量去和常量比較。它就像是在表達(dá) “藍(lán)色是不是天空的顏色” 或者 “高個是不是這個男人的屬性” 而不是 “天空是不是藍(lán)的” 或者 “這個男人是不是高個子的”
（譯者注：名字起源于星球大戰(zhàn)中尤達(dá)大師的講話方式薯嗤，總是用倒裝的語序）
推薦:
if ([myValue isEqual:@42]) { ...
不推薦:
if ([@42 isEqual:myValue]) { ...
nil 和 BOOL 檢查
類似于 Yoda 表達(dá)式顽爹，nil 檢查的方式也是存在爭議的。一些 notous 庫像這樣檢查對象是否為 nil：
if (nil == myValue) { ...
或許有人會提出這是錯的骆姐，因為在 nil 作為一個常量的情況下镜粤，這樣做就像 Yoda 表達(dá)式了。 但是一些程序員這么做的原因是為了避免調(diào)試的困難玻褪，看下面的代碼：
if (myValue == nil) { ...
如果程序員敲錯成這樣：
if (myValue = nil) { ...
這是合法的語句肉渴，但是即使你是一個豐富經(jīng)驗的程序員，即使盯著眼睛瞧上好多遍也很難調(diào)試出錯誤带射。但是如果把 nil 放在左邊同规，因為它不能被賦值，所以就不會發(fā)生這樣的錯誤窟社。 如果程序員這樣做券勺，他/她就可以輕松檢查出可能的原因，比一遍遍檢查敲下的代碼要好很多灿里。
為了避免這些奇怪的問題朱灿，可以用感嘆號來作為運算符。因為 nil 是 解釋到 NO钠四，所以沒必要在條件語句里面把它和其他值比較盗扒。同時，不要直接把它和 YES 比較缀去，因為 YES 的定義是 1侣灶， 而 BOOL 是 8 bit的，實際上是 char 類型缕碎。
推薦:
if (someObject) { ...
if (![someObject boolValue]) { ...
if (!someObject) { ...
不推薦:
if (someObject == YES) { ... // Wrong
if (myRawValue == YES) { ... // Never do this.
if ([someObject boolValue] == NO) { ...
同時這樣也能提高一致性褥影，以及提升可讀性。
黃金大道
在使用條件語句編程時咏雌，代碼的左邊距應(yīng)該是一條“黃金”或者“快樂”的大道凡怎。 也就是說，不要嵌套 if 語句赊抖。使用多個 return 可以避免增加循環(huán)的復(fù)雜度统倒，并提高代碼的可讀性。因為方法的重要部分沒有嵌套在分支里面氛雪，并且你可以很清楚地找到相關(guān)的代碼房匆。
推薦:
- (void)someMethod {
if (![someOther boolValue]) {
return;
}
//Do something important
}
不推薦:
- (void)someMethod {
if ([someOther boolValue]) {
//Do something important
}
}
復(fù)雜的表達(dá)式
當(dāng)你有一個復(fù)雜的 if 子句的時候，你應(yīng)該把它們提取出來賦給一個 BOOL 變量，這樣可以讓邏輯更清楚浴鸿，而且讓每個子句的意義體現(xiàn)出來井氢。
BOOL nameContainsSwift = [sessionName containsString:@"Swift"];
BOOL isCurrentYear = [sessionDateCompontents year] == 2014;
BOOL isSwiftSession = nameContainsSwift && isCurrentYear;
if (isSwiftSession) {
// Do something very cool
}
三元運算符
三元運算符 ? 應(yīng)該只用在它能讓代碼更加清楚的地方。 一個條件語句的所有的變量應(yīng)該是已經(jīng)被求值了的岳链。類似 if 語句花竞，計算多個條件子句通常會讓語句更加難以理解〉а疲或者可以把它們重構(gòu)到實例變量里面约急。
推薦:
result = a > b ? x : y;
不推薦:
result = a > b ? x = c > d ? c : d : y;
當(dāng)三元運算符的第二個參數(shù)（if 分支）返回和條件語句中已經(jīng)檢查的對象一樣的對象的時候，下面的表達(dá)方式更靈巧：
推薦:
result = object ? : [self createObject];
不推薦:
result = object ? object : [self createObject];
錯誤處理
有些方法通過參數(shù)返回 error 的引用举户，使用這樣的方法時應(yīng)當(dāng)檢查方法的返回值，而非 error 的引用遍烦。
推薦:
NSError *error = nil;
if (![self trySomethingWithError:&error]) {
// Handle Error
}
此外俭嘁，一些蘋果的 API 在成功的情況下會對 error 參數(shù)（如果它非 NULL）寫入垃圾值（garbage values），所以如果檢查 error 的值可能導(dǎo)致錯誤 （甚至崩潰）服猪。
Case語句
除非編譯器強(qiáng)制要求供填，括號在 case 語句里面是不必要的。但是當(dāng)一個 case 包含了多行語句的時候罢猪，需要加上括號近她。
switch (condition) {
case 1:
// ...
break;
case 2: {
// ...
// Multi-line example using braces
break;
}
case 3:
// ...
break;
default:
// ...
break;
}
有時候可以使用 fall-through 在不同的 case 里面執(zhí)行同一段代碼。一個 fall-through 是指移除 case 語句的 “break” 然后讓下面的 case 繼續(xù)執(zhí)行膳帕。
switch (condition) {
case 1:
case 2:
// code executed for values 1 and 2
break;
default:
// ...
break;
}
當(dāng)在 switch 語句里面使用一個可枚舉的變量的時候粘捎，default 是不必要的。比如：
switch (menuType) {
case ZOCEnumNone:
// ...
break;
case ZOCEnumValue1:
// ...
break;
case ZOCEnumValue2:
// ...
break;
} ```
此外危彩，為了避免使用默認(rèn)的 case攒磨，如果新的值加入到 enum，程序員會馬上收到一個 warning 通知
``` Enumeration value 'ZOCEnumValue3' not handled in switch.（枚舉類型 'ZOCEnumValue3' 沒有被 switch 處理） ```
## 枚舉類型
當(dāng)使用 enum 的時候汤徽，建議使用新的固定的基礎(chǔ)類型定義娩缰，因為它有更強(qiáng)大的類型檢查和代碼補(bǔ)全。 SDK 現(xiàn)在有一個 宏來鼓勵和促進(jìn)使用固定類型定義 - NS_ENUM()
**例子:**
typedef NS_ENUM(NSUInteger, ZOCMachineState) {
ZOCMachineStateNone,
ZOCMachineStateIdle,
ZOCMachineStateRunning,
ZOCMachineStatePaused
}; ```
命名
通用的約定
盡可能遵守 Apple 的命名約定谒府，尤其是和 內(nèi)存管理規(guī)則 (NARC) 相關(guān)的地方拼坎。
推薦使用長的、描述性的方法和變量名完疫。
推薦:
UIButton *settingsButton; ```
**不推薦:**
UIButton *setBut; ```
常量
常量應(yīng)該以駝峰法命名泰鸡，并以相關(guān)類名作為前綴。
推薦:
static const NSTimeInterval ZOCSignInViewControllerFadeOutAnimationDuration = 0.4; ```
**不推薦:**
static const NSTimeInterval fadeOutTime = 0.4; ```
推薦使用常量來代替字符串字面值和數(shù)字壳鹤，這樣能夠方便復(fù)用鸟顺，而且可以快速修改而不需要查找和替換。常量應(yīng)該用 static 聲明為靜態(tài)常量，而不要用 #define讯嫂，除非它明確的作為一個宏來使用蹦锋。
推薦:
static NSString * const ZOCCacheControllerDidClearCacheNotification = @"ZOCCacheControllerDidClearCacheNotification";
static const CGFloat ZOCImageThumbnailHeight = 50.0f; ```
**不推薦:**
define CompanyName @"Apple Inc."
define magicNumber 42 ```
常量應(yīng)該在頭文件中以這樣的形式暴露給外部：
extern NSString *const ZOCCacheControllerDidClearCacheNotification; ```
并在實現(xiàn)文件中為它賦值欧芽。
只有公有的常量才需要添加命名空間作為前綴莉掂。盡管實現(xiàn)文件中私有常量的命名可以遵循另外一種模式千扔，你仍舊可以遵循這個規(guī)則鹤树。
## 方法
方法名與方法類型 (-/+ 符號)之間應(yīng)該以空格間隔。方法段之間也應(yīng)該以空格間隔（以符合 Apple 風(fēng)格）逊朽。參數(shù)前應(yīng)該總是有一個描述性的關(guān)鍵詞。
盡可能少用 "and" 這個詞叽讳。它不應(yīng)該用來闡明有多個參數(shù)追他，比如下面的 initWithWidth:height: 這個例子：
**推薦:**
- (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; ```
不推薦:
- (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. ```
## 字面值
使用字面值來創(chuàng)建不可變的 `NSString`,` NSDictionary`,` NSArray`, 和 `NSNumber` 對象湿酸。注意不要將 `nil` 傳進(jìn) `NSArray` 和` NSDictionary` 里，因為這樣會導(dǎo)致崩潰灭美。
**例子：**
NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingZIPCode = @10018;
**不要這樣:**
NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];
NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];
NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];
如果要用到這些類的可變副本，我們推薦使用 `NSMutableArray`, `NSMutableString` 這樣的類铁坎。
**應(yīng)該避免下面這樣:**
`NSMutableArray *aMutableArray = [@[] mutableCopy];`
上面這種書寫方式的效率和可讀性的都存在問題。
效率方面犁苏，一個不必要的不可變對象被創(chuàng)建后立馬被廢棄了；雖然這并不會讓你的 App 變慢（除非這個方法被頻繁調(diào)用）围详，但是確實沒必要為了少打幾個字而這樣做祖屏。
可讀性方面，存在兩個問題：第一個問題是當(dāng)你瀏覽代碼并看見 @[] 的時候袁勺，你首先聯(lián)想到的是 NSArray 實例，但是在這種情形下你需要停下來深思熟慮的檢查期丰；另一個問題是，一些新手以他的水平看到你的代碼后可能會對這是一個可變對象還是一個不可變對象產(chǎn)生分歧吃挑。他/她可能不熟悉可變拷貝構(gòu)造的含義（這并不是說這個知識不重要）钝荡。當(dāng)然，不存在絕對的錯誤舶衬，我們只是討論代碼的可用性（包括可讀性)埠通。