我們大致上可以將代碼按執行方式分解為三類：Sequence，Selection，Iteration。

Sequence

Sequence即為按前后順序依次執行，從第一行按序一直執行到第 n 行。比如：

NSString *name = @"default"; //definition 
name = @"peak"; //assignment 
NSLog(@"name is %@", name); //send message 

3 行代碼包含 Definition，Assignment，Send Message 不同類型的指令，但他們被運行的時候作為一個整體是依照 Sequence 模式依次執行。

Selection

Selection即為條件模式，說的簡單一點就是平常我們寫代碼時所用的 if else，switch。這是我們代碼的邏輯產生分支的地方，也是這篇文章的主題。記得之前讀到過一句話，大意說是當我們想要重構代碼的時候，if else 總會是個好的著手點，或者說 if else 是我們代碼最容易出錯的地方。

按我個人理解，邏輯分支之所以容易出錯在于兩點。

其一是所依賴的條件不確定，或者不穩定。比如：

if ([users objectAtIndex:0] == currentUser) { 
    ... 
} 

看似簡單的條件代碼 [users objectAtIndex:0] == currentUser 會在各種情況下出錯，比如 users 當中沒有任何元素會發生越界，比如 users 已被釋放導致內存訪問異常，同樣的情況也會發生在 currentUser 身上，一個條件語句所包含的狀態越多，出錯的可能性也就越大。

其二是遺漏某個條件分支。比如：

typedef enum : NSUInteger { 
  EUserLoginStatusLoggedIn, 
  EUserLoginStatusLoggedOut, 
  EUserLoginStatusKickedOut, 
} EUserLoginStatus; 
 
EUserLoginStatus userStatus; 
... 
if (userStatus == EUserLoginStatusLoggedIn) { 
    ... 
} else if (userStatus == EUserLoginStatusLoggedOut) { 
    ... 
} 

比如上面代碼忘記處理 EUserLoginStatusKickedOut， 當然如果代碼是同一個人所寫，一般不會遺漏。但如果代碼交由后面的人維護，EUserLoginStatus 新增了 status，而 if else 的處理有散落的工程的各個角落，忘記處理新的分支就很容易發生了。

Iteration

Iteration發生在我們需要循環或多次處理某些數據的時候，比如我們常見的 while，for 循環。iteration 有時也會依賴某些數據或者某些條件語句，在處理的時候也會存在 Selection 語句容易遇到的狀態不穩定問題。

Sequence，Selection，Iteration 可以概括我們所寫的全部代碼。其中 Selection 是最容易出錯的地方，也是我個人平時 review 代碼的重點。

Selection 第一個所依賴狀態不穩定的問題，多注意數據或者對象的生命周期，不可變性，多線程安全即可。

分支遺留

第二個分支遺漏的問題，出現的概率比大多數人想象的要高，尤其是隨著項目代碼的膨脹，工程師的更替。所以從代碼層面做一些限制可以有效的避免這一問題出現。

一種常見的做法是針對多分支的邏輯處理，盡量使用 switch 而非 if else，比如工程師 A 先寫了如下代碼：

// File A 
typedef enum : NSUInteger { 
  EUserLoginStatusLoggedIn, 
  EUserLoginStatusLoggedOut, 
} EUserLoginStatus; 
 
// File B 
EUserLoginStatus userStatus; 
... 
switch (userStatus) { 
  case EUserLoginStatusLoggedIn: 
  { 
 
  } 
  break; 
  case EUserLoginStatusLoggedOut: 
  { 
 
  } 
  break; 
} 

之后工程師 B 在 File A 中又加了一種 enum 值 EUserLoginStatusKickedOut，那么此時編譯器會以警告的方式，幫助我們檢查遺漏的類型，這里的關鍵在于寫 switch 時不要寫 default case，否則編譯器會認為新增的 enum 值有默認的處理邏輯了。

如果沒寫 default case，Xcode 會給出如下警告：

這幾乎可以看做是 iOS 下處理邏輯分支的 best practice 了。

Match

除此之外，我們還有另一種更“激進”的方式來避免這類問題，match pattern。過去一年看到越來越多的代碼采用這種方式。使用 match pattern 代碼如下：

// File A 
typedef enum : NSUInteger { 
  EUserLoginStatusLoggedIn, 
  EUserLoginStatusLoggedOut, 
} EUserLoginStatus; 
 
// File B 
typedef void (^UserLoggedInBlock)(void); 
typedef void (^UserLoggedoutBlock)(void); 
 
- (void)someMatchUserStatusLogic 
{ 
  [self matchUserStatusLoggedIn:^{ 
    //... 
  } loggedOut:^{ 
    //... 
  }]; 
} 
 
- (void)matchUserStatusLoggedIn:(UserLoggedInBlock)loggedInBlock loggedOut:(UserLoggedoutBlock)loggedoutBlock 
{ 
  EUserLoginStatus userStatus = EUserLoginStatusLoggedIn; 
  switch (userStatus) { 
    case EUserLoginStatusLoggedIn: 
    { 
      loggedInBlock(); 
    } 
      break; 
    case EUserLoginStatusLoggedOut: 
    { 
      loggedoutBlock(); 
    } 
      break; 
  } 
} 

這種方式在 switch 的基礎之上再封裝了一層函數調用，將分支的處理寫進函數簽名里面，好處很明顯，當你新增 EUserLoginStatusKickedOut case 的時候，只要更改 matchUserStatusLoggedIn 函數，新增一個參數：

// File B 
typedef void (^UserLoggedInBlock)(void); 
typedef void (^UserLoggedoutBlock)(void); 
typedef void (^UserKickedoutBlock)(void); 
 
- (void)matchUserStatusLoggedIn:(UserLoggedInBlock)loggedInBlock loggedOut:(UserLoggedoutBlock)loggedoutBlock kickedOut:(UserKickedoutBlock)kickedoutBlock; 

那么所有被影響的代碼只要一編譯都會報錯，改起來相當方便，相比較于 warning，compile error 顯然更能借助編譯器來避免我們代碼上的分支遺漏。即使代碼被第二個人接手，改動起來也一目了然。

這種寫法如果不明白目的所在，第一眼看上去顯得笨重且多余。我個人感覺，有時候如果多寫的代碼模式固定且簡單容易理解，同時這種多出來的代碼可以讓邏輯更健壯，那么這些多余的代碼就并不多余。尤其是當項目代碼量過于龐大且參與人數眾多的情況下，優質的代碼書寫避免代碼產生意料之外的降級。