人生在世，我們每天都需要進行三項重大選擇：早餐吃什么，午餐吃什么，晚餐吃什么。這一度讓我感到非常為難，于是我養(yǎng)成了一個習慣，只要在附近的餐館發(fā)現(xiàn)了幾種還不錯的食物，我就會連續(xù)一段時間一直吃它們，直到吃膩，再嘗試一下別的選擇，直到又發(fā)現(xiàn)還比較對胃口的，就再一直吃，如此循環(huán)往復(fù)。

[[155301]]

對于程序員來說，做選擇是一件很客觀理性的事情，需要根據(jù)現(xiàn)有條件進行分析判斷從而做出一個正確的或者***的決定。比如吃什么這個事情，可能的限制條件有很多，譬如：

• 我是個很懶的人，吃飯地點就定在公司附近500米，于是選擇范圍限定在了500米以內(nèi)的餐館
• 我有鼻炎，不能吃辣，而且我對青椒心理過敏，所以辛辣食物以及帶青椒的食物被排除
• 這個月手頭有點緊，一頓50以上的不考慮
• ……

由于我不是個吃貨，很少有明確想吃什么的時候，所以對于吃飯這件事情來說影響因素實在太多，而且很多因素都很主觀，如果要考慮所有因素的話就得深入探索自己的內(nèi)心世界（性能消耗太大，大腦已死機）……如果不同的因素之間產(chǎn)生了矛盾就需要進行權(quán)衡，做出合理的犧牲，最普適的方法就是給所有的因素定一個優(yōu)先級或者權(quán)重，這實在是太麻煩了（唉我突然發(fā)現(xiàn)可以做個App，讓用戶選擇幾個選項，譬如吃不吃辣，限定就餐范圍等等，然后進行自動計算幫助用戶選擇今天吃什么，或許會挺有市場- -），于是我個人選擇了暴力破解法——隨機嘗試，碰到合適的就多吃幾頓。

好了說正經(jīng)的，其實編程跟做人一樣，也時刻面臨著選擇，暫且拋開架構(gòu)選擇、模式選擇、語言選擇、框架選擇等內(nèi)容，今天我想談?wù)劤绦蛘Z言中的條件分支結(jié)構(gòu)。

很多人覺得，對于偏向于業(yè)務(wù)的后端開發(fā)人員來說，整天寫得最多的就是各種增刪改查，其實不是的，他們明明是整天在調(diào)接口和寫if-else（大霧）。我早先是寫Java的，現(xiàn)在在公司差不多是自己獨立開發(fā)一個iOS項目，也是說服務(wù)器端的API也是自己寫（用C#），也算得上半個后端，但是我平常不會寫很多if-else。大量的if-else嵌套不僅可讀性差而且容易出錯又難以調(diào)試，所以其實不管做什么開發(fā)，只要是寫代碼，大量的if-else都是應(yīng)該盡量避免的。那應(yīng)該如何避免呢？

首先，理清思路，保持冷靜，不要做無謂的判斷，不要一時意亂情迷熱血上涌就寫下這樣的代碼(以Swift為例)：

//你愛或者不愛我 
if you.love(me) || !you.love(me) { 
    // 愛就在那里 
    Love.isRightThere() 
    //不增不減 
    Love.level++ 
    Love.level-- 
} 

我們假設(shè)func love(someone: Person) -> Bool這個函數(shù)是個冪等函數(shù)，也就是每次調(diào)用它產(chǎn)生的結(jié)果都是一致的，那上面這段代碼顯然是有問題的，因為you.love(me) || !you.love(me)這部分是永真的(無論true || false還是false || true，結(jié)果都是true)，所以這是句廢話，可以直接刪掉。你可能覺得上面這段代碼就是個玩笑，平常誰會寫出這樣的代碼，那我再舉個例子：return a == b ? a : b,是不是覺得還挺正常的？你再仔細看看……

好了，我們接下去說。if-else很多時候會被用來進行邊界條件的處理，對于這種情況，我們***是提前return而不是用else，而且在Swift2.0之后，多了一個新的關(guān)鍵字——guard，非常好用。譬如：

func handle(optionalData: Int?) -> Bool { 
    if let data = optionalData { 
        if data > 0 && data < 31 { 
            doSomethingWith(data) 
            return true 
        } else { 
            return false 
        } 
    } else { 
        return false 
    } 
} 

這段代碼的邏輯很簡單，接受一個可能為空的整數(shù)，先判斷它是否為空，如果不為空就取它的值，然后判斷是否在0到31之間，如果在的話就把值傳遞給doSomethingWith(data: Int)函數(shù)然后執(zhí)行，返回true，其余情況都返回false。錯是沒錯，但是真的丑啊- -#，我們把它改成這樣：

func handle(optionalData: Int?) -> Bool { 
    guard let data = optionalData where data > 0 && data < 31 else { 
        return false 
    } 
 
    doSomethingWith(data) 
    return true 
} 

做的事情完全相同，只是在函數(shù)開始的時候做了提前返回，也就是使用了所謂的衛(wèi)語句，之后只需要正常處理數(shù)據(jù)就好了，大大提高了代碼可讀性。

還有就是要善于使用條件表達式，就是<條件> ? <表達式1> : <表達式2>這種?？催^《CSAPP》（《深入理解計算機系統(tǒng)》）的朋友應(yīng)該記得，書中有提到現(xiàn)代處理器通過使用流水線（pipelining）來獲得高性能，當執(zhí)行順序代碼的時候，流水線中充滿了待執(zhí)行的指令。但是當機器遇到條件分支時，它常常還不能確定是否會進行跳轉(zhuǎn)，處理器采用非常精密的分支預(yù)測邏輯試圖猜測每條跳轉(zhuǎn)指令是否會執(zhí)行。只要它的猜測還比較可靠，指令流水線中就會充滿指令。然而如果預(yù)測跳轉(zhuǎn)出錯，那就得丟掉它為該跳轉(zhuǎn)指令后所有指令所做的工作，然后再用正確跳轉(zhuǎn)后的指令去填充流水線，這就是錯誤預(yù)測懲罰。相對于基于控制的條件轉(zhuǎn)移，有一種替代策略是數(shù)據(jù)的條件轉(zhuǎn)移，這種方法先計算一個條件操作的兩種結(jié)果，然后再根據(jù)條件是否滿足從而選取一個，只有在一些受限制的情況下，這種策略才可行，一旦可行，就可以用一條簡單的條件傳送指令（現(xiàn)代處理器都擁有）來實現(xiàn)它。當然在語言層面是不能直接控制的，不過至少對于GCC（GNU開發(fā)的編譯器套件）來說，條件表達式（? :）比條件分支語句（if-else）更容易被翻譯成條件傳送。

上面說了這么多關(guān)于性能的東西，不過我覺得在實際開發(fā)過程中還是應(yīng)該著眼于代碼的可讀性和可維護性，性能優(yōu)化還是要靠性能分析工具確定性能瓶頸進行針對性的優(yōu)化。畢竟 ——

代碼是寫給人看的, 只是恰好能在機器上運行。

然而如果某種寫法具有良好的可讀性，又恰好有可能對性能提高有所幫助的話，那能用就用吧，譬如：

func getMin(num1: Int, num2: Int) -> Int { 
    var min = num1 
    if num1 > num2 { 
        min = num2 
    } 
    return min 
} 

直接改為:

func getMin(num1: Int, num2: Int) -> Int { 
    return num1 > num2 ? num2 : num1 
} 

還有?? 操作符的使用，譬如判斷某個值是否為空,如果為空則給它一個默認值：

//最不好的方式 
func getData(optionalData: Int?) -> Int { 
    let defaultData = 0 
    if optionalData == nil { 
        return defaultData 
    } else { 
        return optionalData! 
    } 
} 
 
//稍微好一點的方式(if let) 
func getData(optionalData: Int?) -> Int { 
    let defaultData = 0 
    if let data = optionalData { 
        return data 
    } else { 
        return defaultData 
    } 
} 
 
//推薦方式(??) 
func getData(optionalData: Int?) -> Int { 
    let defaultData = 0 
    return optionalData ?? defaultData 
} 

值得一提的是，??這個操作符在Swift中的定義有兩個版本:

@warn_unused_result 
@rethrows public func ??<T>(optional: T?, @autoclosure defaultValue: () throws -> T?) rethrows -> T? 
 
@warn_unused_result 
@rethrows public func ??<T>(optional: T?, @autoclosure defaultValue: () throws -> T) rethrows -> T 

我們的例子滿足的是第二種情況，可以注意到這里使用了@autoclosure這個關(guān)鍵字，它可以把一句表達式自動封裝為一個閉包，也就是說在??真正取值之前defaultValue這個表達式的值并沒有被計算出來準備好，而是會延遲到判定optional為nil之后。舉個例子:

let optional: Int? = 2 
//optional不為nil，所以后面的9 * 1000 / 6 + 55根本不會執(zhí)行 
let value = optional ?? 9 * 1000 / 6 + 55  //value = 2 

這里跟《CSAPP》中的說法似乎有點矛盾（當然書中也說了，只有在一些受限制的情況下，條件傳送策略才可行），Swift語言的設(shè)計者并不想讓使用??的代碼被翻譯成條件傳送形式，而是認為使用閉包進行延遲計算可以避免不必要的開銷。

***讓我們談?wù)剆witch語句吧，在C語言中，switch語句可以根據(jù)一個整數(shù)索引值進行多重分支，不僅提高了C代碼的可讀性，而且通過使用跳轉(zhuǎn)表（jump table）這種數(shù)據(jù)結(jié)構(gòu)使得實現(xiàn)更加高效。GCC根據(jù)case的數(shù)量和匹配值的***程度（sparsity）來翻譯switch語句，當case數(shù)量比較多（如4個以上），值的范圍跨度比較小時，就會使用跳轉(zhuǎn)表，跳轉(zhuǎn)表是一個存儲著代碼段內(nèi)存地址(即函數(shù)的指針)的數(shù)組，可以根據(jù)索引直接跳轉(zhuǎn)到相應(yīng)代碼段然后執(zhí)行，和一組很長的if-else語句相比，使用跳轉(zhuǎn)表的優(yōu)點是執(zhí)行switch語句的時間與case的數(shù)量無關(guān)。

而在Swift中，switch后面跟的不是索引，而是一個待匹配的值。Swfit的模式匹配還比較初級，只支持相等匹配和范圍匹配，使用~=作為模式匹配的操作符，switch其實就是用它來進行模式匹配的。我們看看API中~=的幾個聲明版本：

@warn_unused_result 
public func ~=<I : ForwardIndexType where I : Comparable>(pattern: Range<I>, value: I) -> Bool 
 
@warn_unused_result 
public func ~=<T : Equatable>(a: T, b: T) -> Bool 
 
@warn_unused_result 
public func ~=<T>(lhs: _OptionalNilComparisonType, rhs: T?) -> Bool 
 
/// Returns `true` iff `pattern` contains `value`. 
@warn_unused_result 
public func ~=<I : IntervalType>(pattern: I, value: I.Bound) -> Bool 

它們接收不同的參數(shù)，從上往下依次是：某種可比較類型（數(shù)字和String）的范圍輸入和該類型的值、可以判等的類型、可以與nil比較的類型、一個范圍輸入和某個特定值的類型。返回值都是Bool。下面列舉幾種switch的常見用法：

///對可以判等類型的判斷 
let password = "password" 
switch password { 
case "password": 
    print("登錄成功") 
default: 
    print("密碼錯誤") 
} 
//與枚舉類型配合 
enum Direction { 
    case North 
    case South 
    case East 
    case West 
} 
func goTo(direction: Direction) { 
    switch direction { 
    case .North: 
        print("go to north") 
    case .South: 
        print("go to south") 
    case .East: 
        print("go to east") 
    case .West: 
        print("go to west") 
    } 
} 
 
///對范圍的判斷 
let num = 0 
switch num { 
case -1...1: 
    print("In Range") 
default: 
    print("Out Range") 
} 

簡單總結(jié)一下減少if-else，提高代碼可讀性的幾種方法：

• 理清思路，優(yōu)化邏輯，合并重復(fù)的判斷，不做無謂的判斷。
• 使用衛(wèi)語句。
• 使用條件表達式。
• 使用模式匹配。

把代碼寫正確并不難，難的是寫出高質(zhì)量的代碼，與諸君共勉。寫得腰都酸了~