以下是文章原文， 如有侵權請告知
條件語句
條件語句體應該總是被大括號包圍。盡管有時候你可以不使用大括號（比如，條件語句體只有一行內容），但是這樣做會帶來問題隱患。比如，增加一行代碼時，你可能會誤以為它是 if 語句體里面的。此外，更危險的是，如果把 if 后面的那行代碼注釋掉，之后的一行代碼會成為 if 語句里的代碼。
推薦:
if (!error) {
return success;
}
不推薦:
if (!error)
return success;
和
if (!error) return success;
在 2014年2月 蘋果的 SSL/TLS 實現里面發現了知名的 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行連續的 goto fail; 。我們當然不希望寫出上面的代碼導致錯誤。
此外，在其他條件語句里面也應該按照這種風格統一，這樣更便于檢查。
尤達表達式
不要使用尤達表達式。尤達表達式是指，拿一個常量去和變量比較而不是拿變量去和常量比較。它就像是在表達 “藍色是不是天空的顏色” 或者 “高個是不是這個男人的屬性” 而不是 “天空是不是藍的” 或者 “這個男人是不是高個子的”
（譯者注：名字起源于星球大戰中尤達大師的講話方式，總是用倒裝的語序）
推薦:
if ([myValue isEqual:@42]) { ...
不推薦:
if ([@42 isEqual:myValue]) { ...
nil 和 BOOL 檢查
類似于 Yoda 表達式，nil 檢查的方式也是存在爭議的。一些 notous 庫像這樣檢查對象是否為 nil：
if (nil == myValue) { ...
或許有人會提出這是錯的，因為在 nil 作為一個常量的情況下，這樣做就像 Yoda 表達式了。 但是一些程序員這么做的原因是為了避免調試的困難，看下面的代碼：
if (myValue == nil) { ...
如果程序員敲錯成這樣：
if (myValue = nil) { ...
這是合法的語句，但是即使你是一個豐富經驗的程序員，即使盯著眼睛瞧上好多遍也很難調試出錯誤。但是如果把 nil 放在左邊，因為它不能被賦值，所以就不會發生這樣的錯誤。 如果程序員這樣做，他/她就可以輕松檢查出可能的原因，比一遍遍檢查敲下的代碼要好很多。
為了避免這些奇怪的問題，可以用感嘆號來作為運算符。因為 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) { ...
同時這樣也能提高一致性，以及提升可讀性。
黃金大道
在使用條件語句編程時，代碼的左邊距應該是一條“黃金”或者“快樂”的大道。 也就是說，不要嵌套 if 語句。使用多個 return 可以避免增加循環的復雜度，并提高代碼的可讀性。因為方法的重要部分沒有嵌套在分支里面，并且你可以很清楚地找到相關的代碼。
推薦:
- (void)someMethod {
if (![someOther boolValue]) {
return;
}
//Do something important
}
不推薦:
- (void)someMethod {
if ([someOther boolValue]) {
//Do something important
}
}
復雜的表達式
當你有一個復雜的 if 子句的時候，你應該把它們提取出來賦給一個 BOOL 變量，這樣可以讓邏輯更清楚，而且讓每個子句的意義體現出來。
BOOL nameContainsSwift = [sessionName containsString:@"Swift"];
BOOL isCurrentYear = [sessionDateCompontents year] == 2014;
BOOL isSwiftSession = nameContainsSwift && isCurrentYear;
if (isSwiftSession) {
// Do something very cool
}
三元運算符
三元運算符 ? 應該只用在它能讓代碼更加清楚的地方。 一個條件語句的所有的變量應該是已經被求值了的。類似 if 語句，計算多個條件子句通常會讓語句更加難以理解。或者可以把它們重構到實例變量里面。
推薦:
result = a > b ? x : y;
不推薦:
result = a > b ? x = c > d ? c : d : y;
當三元運算符的第二個參數（if 分支）返回和條件語句中已經檢查的對象一樣的對象的時候，下面的表達方式更靈巧：
推薦:
result = object ? : [self createObject];
不推薦:
result = object ? object : [self createObject];
錯誤處理
有些方法通過參數返回 error 的引用，使用這樣的方法時應當檢查方法的返回值，而非 error 的引用。
推薦:
NSError *error = nil;
if (![self trySomethingWithError:&error]) {
// Handle Error
}
此外，一些蘋果的 API 在成功的情況下會對 error 參數（如果它非 NULL）寫入垃圾值（garbage values），所以如果檢查 error 的值可能導致錯誤 （甚至崩潰）。
Case語句
除非編譯器強制要求，括號在 case 語句里面是不必要的。但是當一個 case 包含了多行語句的時候，需要加上括號。
switch (condition) {
case 1:
// ...
break;
case 2: {
// ...
// Multi-line example using braces
break;
}
case 3:
// ...
break;
default:
// ...
break;
}
有時候可以使用 fall-through 在不同的 case 里面執行同一段代碼。一個 fall-through 是指移除 case 語句的 “break” 然后讓下面的 case 繼續執行。
switch (condition) {
case 1:
case 2:
// code executed for values 1 and 2
break;
default:
// ...
break;
}
當在 switch 語句里面使用一個可枚舉的變量的時候，default 是不必要的。比如：
switch (menuType) {
case ZOCEnumNone:
// ...
break;
case ZOCEnumValue1:
// ...
break;
case ZOCEnumValue2:
// ...
break;
} ```
此外，為了避免使用默認的 case，如果新的值加入到 enum，程序員會馬上收到一個 warning 通知
``` Enumeration value 'ZOCEnumValue3' not handled in switch.（枚舉類型 'ZOCEnumValue3' 沒有被 switch 處理） ```
## 枚舉類型
當使用 enum 的時候，建議使用新的固定的基礎類型定義，因為它有更強大的類型檢查和代碼補全。 SDK 現在有一個 宏來鼓勵和促進使用固定類型定義 - NS_ENUM()
**例子:**
typedef NS_ENUM(NSUInteger, ZOCMachineState) {
ZOCMachineStateNone,
ZOCMachineStateIdle,
ZOCMachineStateRunning,
ZOCMachineStatePaused
}; ```
命名
通用的約定
盡可能遵守 Apple 的命名約定，尤其是和 內存管理規則 (NARC) 相關的地方。
推薦使用長的、描述性的方法和變量名。
推薦:
UIButton *settingsButton; ```
**不推薦:**
UIButton *setBut; ```
常量
常量應該以駝峰法命名，并以相關類名作為前綴。
推薦:
static const NSTimeInterval ZOCSignInViewControllerFadeOutAnimationDuration = 0.4; ```
**不推薦:**
static const NSTimeInterval fadeOutTime = 0.4; ```
推薦使用常量來代替字符串字面值和數字，這樣能夠方便復用，而且可以快速修改而不需要查找和替換。常量應該用 static 聲明為靜態常量，而不要用 #define，除非它明確的作為一個宏來使用。
推薦:
static NSString * const ZOCCacheControllerDidClearCacheNotification = @"ZOCCacheControllerDidClearCacheNotification";
static const CGFloat ZOCImageThumbnailHeight = 50.0f; ```
**不推薦:**
define CompanyName @"Apple Inc."
define magicNumber 42 ```
常量應該在頭文件中以這樣的形式暴露給外部：
extern NSString *const ZOCCacheControllerDidClearCacheNotification; ```
并在實現文件中為它賦值。
只有公有的常量才需要添加命名空間作為前綴。盡管實現文件中私有常量的命名可以遵循另外一種模式，你仍舊可以遵循這個規則。
## 方法
方法名與方法類型 (-/+ 符號)之間應該以空格間隔。方法段之間也應該以空格間隔（以符合 Apple 風格）。參數前應該總是有一個描述性的關鍵詞。
盡可能少用 "and" 這個詞。它不應該用來闡明有多個參數，比如下面的 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. ```
## 字面值
使用字面值來創建不可變的 `NSString`,` NSDictionary`,` NSArray`, 和 `NSNumber` 對象。注意不要將 `nil` 傳進 `NSArray` 和` NSDictionary` 里，因為這樣會導致崩潰。
**例子：**
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` 這樣的類。
**應該避免下面這樣:**
`NSMutableArray *aMutableArray = [@[] mutableCopy];`
上面這種書寫方式的效率和可讀性的都存在問題。
效率方面，一個不必要的不可變對象被創建后立馬被廢棄了；雖然這并不會讓你的 App 變慢（除非這個方法被頻繁調用），但是確實沒必要為了少打幾個字而這樣做。
可讀性方面，存在兩個問題：第一個問題是當你瀏覽代碼并看見 @[] 的時候，你首先聯想到的是 NSArray 實例，但是在這種情形下你需要停下來深思熟慮的檢查；另一個問題是，一些新手以他的水平看到你的代碼后可能會對這是一個可變對象還是一個不可變對象產生分歧。他/她可能不熟悉可變拷貝構造的含義（這并不是說這個知識不重要）。當然，不存在絕對的錯誤，我們只是討論代碼的可用性（包括可讀性)。