我們大致上可以將代碼按執(zhí)行方式分解為三類:Sequence弹渔,Selection,Iteration溯祸。
Sequence
Sequence 即為按前后順序依次執(zhí)行肢专,從第一行按序一直執(zhí)行到第 n 行。比如:
NSString *name = @"default"; //definition
name = @"peak"; //assignment
NSLog(@"name is %@", name); //send message
3 行代碼包含 Definition博杖,Assignment,Send Message 不同類型的指令狈醉,但他們被運行的時候作為一個整體是依照 Sequence 模式依次執(zhí)行班巩。
Selection
Selection 即為條件模式逊桦,說的簡單一點就是平常我們寫代碼時所用的 if else,switch宝穗。這是我們代碼的邏輯產(chǎn)生分支的地方,也是這篇文章的主題。記得之前讀到過一句話,大意說是當我們想要重構代碼的時候,if else 總會是個好的著手點不铆,或者說 if else 是我們代碼最容易出錯的地方。
按我個人理解,邏輯分支之所以容易出錯在于兩點涝开。
其一是所依賴的條件不確定,或者不穩(wěn)定捐腿。比如:
if ([users objectAtIndex:0] == currentUser) {
...
}
看似簡單的條件代碼 [users objectAtIndex:0] == currentUser
會在各種情況下出錯嘁锯,比如 users 當中沒有任何元素會發(fā)生越界蝗羊,比如 users 已被釋放導致內(nèi)存訪問異常,同樣的情況也會發(fā)生在 currentUser 身上蓄愁,一個條件語句所包含的狀態(tài)越多效诅,出錯的可能性也就越大。
其二是遺漏某個條件分支剑刑。比如:
typedef enum : NSUInteger {
EUserLoginStatusLoggedIn,
EUserLoginStatusLoggedOut,
EUserLoginStatusKickedOut,
} EUserLoginStatus;
EUserLoginStatus userStatus;
...
if (userStatus == EUserLoginStatusLoggedIn) {
...
} else if (userStatus == EUserLoginStatusLoggedOut) {
...
}
比如上面代碼忘記處理 EUserLoginStatusKickedOut, 當然如果代碼是同一個人所寫狸驳,一般不會遺漏辩昆。但如果代碼交由后面的人維護术辐,EUserLoginStatus 新增了 status,而 if else 的處理有散落的工程的各個角落,忘記處理新的分支就很容易發(fā)生了襟企。
Iteration
Iteration 發(fā)生在我們需要循環(huán)或多次處理某些數(shù)據(jù)的時候,比如我們常見的 while木羹,for 循環(huán)脐瑰。iteration 有時也會依賴某些數(shù)據(jù)或者某些條件語句,在處理的時候也會存在 Selection 語句容易遇到的狀態(tài)不穩(wěn)定問題掠剑。
Sequence朴译,Selection,Iteration 可以概括我們所寫的全部代碼盯拱。其中 Selection 是最容易出錯的地方蛮艰,也是我個人平時 review 代碼的重點。
Selection 第一個所依賴狀態(tài)不穩(wěn)定的問題窒盐,多注意數(shù)據(jù)或者對象的生命周期,不可變性,多線程安全即可梅肤∈谂粒可以參考下我之前的兩篇文章 [書寫高質(zhì)量代碼之狀態(tài)維護], [iOS多線程到底不安全在哪里缝裤?],里面有一些我的相關思考和總結锰瘸,或許會對你有一些幫助。
分支遺留
第二個分支遺漏的問題,出現(xiàn)的概率比大多數(shù)人想象的要高调鬓,尤其是隨著項目代碼的膨脹缀踪,工程師的更替。所以從代碼層面做一些限制可以有效的避免這一問題出現(xiàn)。
一種常見的做法是針對多分支的邏輯處理咒彤,盡量使用 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 的基礎之上再封裝了一層函數(shù)調(diào)用裂七,將分支的處理寫進函數(shù)簽名里面,好處很明顯仓坞,當你新增 EUserLoginStatusKickedOut case 的時候背零,只要更改 matchUserStatusLoggedIn 函數(shù),新增一個參數(shù):
// 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 顯然更能借助編譯器來避免我們代碼上的分支遺漏嫉称。即使代碼被第二個人接手侦镇,改動起來也一目了然。
這種寫法如果不明白目的所在织阅,第一眼看上去顯得笨重且多余壳繁。我個人感覺,有時候如果多寫的代碼模式固定且簡單容易理解荔棉,同時這種多出來的代碼可以讓邏輯更健壯闹炉,那么這些多余的代碼就并不多余。尤其是當項目代碼量過于龐大且參與人數(shù)眾多的情況下润樱,優(yōu)質(zhì)的代碼書寫避免代碼產(chǎn)生意料之外的降級渣触。