Swift 2.0 帶來了令人激動(dòng)的guard語句。但很多人還是不太理解guard的意義，特別是和 Swift 2.0 之前的簡單if語句相比較。

為什么guard就是比if要好呢?

與if語句相同的是，guard也是基于一個(gè)表達(dá)式的布爾值去判斷一段代碼是否該被執(zhí)行。與if語句不同的是，guard只有在條件不滿足的時(shí)候才會(huì)執(zhí)行這段代碼。你可以把guard近似的看做是Assert，但是你可以優(yōu)雅的退出而非崩潰。

具體細(xì)節(jié)

讓我們用一個(gè)簡單的對(duì)比來比較一下現(xiàn)在的寫法和用全新guard語句的寫法：

func fooManualCheck(x: Int?) {

if x == nil || x = 0 {

// 不符合值的要求時(shí)，寫點(diǎn)代碼

return

}

// 使用x

x!.description

}

這是最基本的Objective-C方式來保證一個(gè)變量真的存在并符合一個(gè)條件。沒什么大問題，但是有一些缺點(diǎn)：

你是在檢查一個(gè)不符合你期望的條件，而非檢查你想要的值。如果你加了一堆像這樣的條件判斷，代碼就變的不好理解。你在這里其實(shí)是等著你的條件通不過。

如果前面條件判斷的結(jié)果不符合了，你還得將你的變量強(qiáng)制拆包。

Swift通過可選綁定讓問題變得簡單了一些，并解決了上面的部分缺點(diǎn)：

func fooBinding(x: Int?) {

if let x = x where x > 0 {

// 使用x

x.description

}

// 如果值不符合條件判斷，就執(zhí)行下面的代碼

}

這個(gè)函數(shù)沒有了第一個(gè)函數(shù)的2個(gè)缺陷，但引入了一個(gè)新的。你把你要寫的代碼都放在了所有條件判斷中，而不是之后。你可能不會(huì)馬上意識(shí)到這個(gè)問題，但是你可以想象在你的代碼被執(zhí)行之前，如果嵌套了好多需要被匹配的條件判斷，這會(huì)變的多難讀懂。

對(duì)此的解決方法是先對(duì)每個(gè)條件逐一做檢查，如果不符合條件判斷就退出。這就會(huì)讓人容易看出來什么條件會(huì)讓這個(gè)函數(shù)退出。

我聽說過這個(gè)叫保鏢模式(Bouncer Pattern)，這個(gè)模式十分的合理。你要在壞情況進(jìn)門之前把它們擋出去。這讓你每次只考慮一種情況，而不用去搞清楚如何同時(shí)將所有的條件判斷安排在一起。

這就是guard語句：

func fooGuard(x: Int?) {

guard let x = x where x > 0 else {

// 變量不符合條件判斷時(shí)，執(zhí)行下面代碼

return

}

// 使用x

x.description

}

使用guard語句將上述的3個(gè)問題一并解決：

是對(duì)你所期望的條件做檢查，而非不符合你期望的。又是和assert很相似。如果條件不符合，guard的else語句就運(yùn)行，從而退出這個(gè)函數(shù)。

如果通過了條件判斷，可選類型的變量在guard語句被調(diào)用的范圍內(nèi)會(huì)被自動(dòng)的拆包 - 這個(gè)例子中該范圍是fooGuard函數(shù)內(nèi)部。這是一個(gè)很重要，卻有點(diǎn)奇怪的特性，但讓guard語句十分實(shí)用。

對(duì)你所不期望的情況早做檢查，使得你寫的函數(shù)更易讀，更易維護(hù)。

對(duì)非可選類型的變量這種用法也是奏效的：

func fooNonOptionalGood(x: Int) {

guard x > 0 else {

// 變量不符合條件判斷時(shí)，執(zhí)行下面代碼

return

}

// 使用x

}

func fooNonOptionalBad(x: Int) {

if x = 0 {

// 變量不符合條件判斷時(shí)，執(zhí)行下面代碼

return

}

// 使用x

}

再給一個(gè)示例對(duì)比，使用guard和if

總結(jié)

希望上面這個(gè)簡單的例子告訴你可以馬上在你的swift代碼中使用guard，從而讓你的函數(shù)/方法更清楚。