1. 把運(yùn)算符當(dāng)成決策細(xì)胞來(lái)理解1.1 運(yùn)算符的本質(zhì)從一次計(jì)算到一次判斷很多人學(xué)編程時(shí)運(yùn)算符是被一筆帶過(guò)的基礎(chǔ)章節(jié)。但我一直覺(jué)得運(yùn)算符才是整個(gè)程序流程控制里最核心的細(xì)胞。為什么這么說(shuō)因?yàn)椴还苣闶菍慽f還是switch本質(zhì)都是在問(wèn)一個(gè)問(wèn)題這個(gè)條件到底成不成立而條件是否成立幾乎全部依賴運(yùn)算符產(chǎn)生的結(jié)果。運(yùn)算符的本質(zhì)就一句話把操作數(shù)變量、常量、表達(dá)式變換成一個(gè)新的值順帶可能產(chǎn)生副作用。比如a b把兩個(gè)數(shù)變成它們的和這是一個(gè)純計(jì)算通常不會(huì)改變a或b本身而a這類的自增運(yùn)算符除了返回一個(gè)值還會(huì)改變a的內(nèi)存內(nèi)容這就是副作用。理解這一點(diǎn)非常關(guān)鍵。因?yàn)闂l件語(yǔ)句里的一句話if (score 60)其真正的運(yùn)行過(guò)程是先讓score 60這個(gè)比較表達(dá)式產(chǎn)生一個(gè)布爾結(jié)果true或false然后if再根據(jù)這個(gè)結(jié)果決定走哪條分支。你可以把運(yùn)算符理解為制造判斷依據(jù)的機(jī)器而條件語(yǔ)句是依據(jù)判斷結(jié)果分配路徑的調(diào)度員。沒(méi)有前者后者就是無(wú)源之水。所以我的建議是別把運(yùn)算符當(dāng)計(jì)算題學(xué)要當(dāng)決策工具學(xué)。比如你寫一個(gè)用戶登錄邏輯用戶名不為空并且密碼匹配這個(gè)條件拆開(kāi)看就是兩個(gè)比較運(yùn)算加一個(gè)邏輯與運(yùn)算最終產(chǎn)出一個(gè)布爾值。一旦你用這個(gè)視角看代碼你會(huì)發(fā)現(xiàn)所謂復(fù)雜的流程控制其實(shí)都是運(yùn)算符制造條件分支語(yǔ)句分派路徑的循環(huán)組合。1.2 五類核心運(yùn)算符逐個(gè)拆解我先按實(shí)際使用頻率把最核心的幾類運(yùn)算符過(guò)一遍。注意這里我不打算按教科書(shū)順序平鋪而是按它們?nèi)绾卧跅l件判斷里起作用來(lái)講。算術(shù)運(yùn)算符 - * / %。這里重點(diǎn)說(shuō)%取余。它除了算奇偶、算倍數(shù)更大的價(jià)值是為后續(xù)條件判斷提供分類依據(jù)。比如輪詢調(diào)度中index % 3可以把請(qǐng)求均勻分到三臺(tái)服務(wù)器分頁(yè)中offset % pageSize可以判斷是否到了邊界。%的結(jié)果天然適合放進(jìn)switch或if去做分支。另外 Python 里**是冪運(yùn)算符寫2 ** 10就能得到 1024C/C/Java 里則沒(méi)有這個(gè)語(yǔ)法需要用pow()函數(shù)這是跨語(yǔ)言時(shí)很容易踩的差異。賦值運(yùn)算符 - * / %。是賦值不是數(shù)學(xué)上的等于。a 5等價(jià)于a a 5。賦值運(yùn)算本身也有值這個(gè)值就是賦完后的結(jié)果所以a b 0可以把b和a連續(xù)賦值為 0。但正因?yàn)橘x值表達(dá)式有值才會(huì)出現(xiàn)后面要講的大坑把寫成。比較運(yùn)算符 ! 。它們的結(jié)果永遠(yuǎn)是布爾值。這里必須強(qiáng)調(diào)一個(gè)區(qū)別是比較值是否相等是賦值。在很多語(yǔ)言里if (x 5)不是報(bào)錯(cuò)而是把x賦成 5然后判斷5 是否為真在 C/C 里這個(gè)條件恒為真于是你的程序會(huì)無(wú)條件地走進(jìn)分支。這個(gè)錯(cuò)誤極其隱蔽因?yàn)榇a能編譯、能運(yùn)行但邏輯完全錯(cuò)了。后面我會(huì)專門講排查方法。邏輯運(yùn)算符 || !。與、||或、!非。它們操作的是布爾邏輯是條件語(yǔ)句里最常用的組合工具。重點(diǎn)在于短路求值a b中如果a為假b根本不會(huì)執(zhí)行a || b中如果a為真b也不會(huì)執(zhí)行。這不只是性能優(yōu)化更是安全手段。比如寫if (ptr ! NULL ptr-value 10)當(dāng)ptr是空指針時(shí)后面的ptr-value壓根不會(huì)求值從而避免了空指針崩潰。位運(yùn)算符 | ^ ~ 。這是很多初學(xué)者直接跳過(guò)的東西但它才是真正體現(xiàn)計(jì)算機(jī)思維的運(yùn)算符。按位與、|按位或、^按位異或、~按位取反、左移、右移。位運(yùn)算最常見(jiàn)的用途是掩碼和權(quán)限判斷。比如一個(gè)整數(shù)的低 4 位分別代表讀、寫、執(zhí)行、刪除四種權(quán)限if ((permission 0x08) ! 0)就能判斷刪除權(quán)限是否開(kāi)啟。位運(yùn)算在條件判斷里極其高效而且能極大壓縮狀態(tài)空間。三目運(yùn)算符condition ? expr1 : expr2。這是唯一一個(gè)三目運(yùn)算符也是把條件判斷壓縮進(jìn)表達(dá)式的利器。它有一個(gè)需要特別注意的特性結(jié)合方向是從右往左。也就是說(shuō)a ? b : c ? d : e實(shí)際解析為a ? b : (c ? d : e)。這個(gè)特性常被拿來(lái)出題但在實(shí)際代碼里我強(qiáng)烈建議三目運(yùn)算符最多只嵌套一層超過(guò)一層直接寫if-else否則代碼可讀性會(huì)急劇下降。2. 優(yōu)先級(jí)程序按你的潛臺(tái)詞運(yùn)行2.1 一張表看懂優(yōu)先級(jí)與結(jié)合性運(yùn)算符優(yōu)先級(jí)是個(gè)老生常談的話題但真正把它吃透的人不多。我見(jiàn)過(guò)太多代碼事故最后排查到根因都是優(yōu)先級(jí)理解錯(cuò)了。你可以不背整張表但必須記住一個(gè)分層原則先算算術(shù)再比大小再判邏輯最后賦值。更細(xì)一點(diǎn)核心排序如下從高到低括號(hào)()、下標(biāo)[]、成員訪問(wèn).最高一元運(yùn)算符 -- ! ~算術(shù)運(yùn)算符* / %高于 -移位 關(guān)系比較 相等比較 !按位與按位異或^按位或|邏輯與邏輯或||三目?:賦值 -等逗號(hào),最低結(jié)合性也需要留意。算術(shù)、關(guān)系、位、邏輯這四類都是從左往右結(jié)合而賦值和三目是從右往左結(jié)合。所以a b c會(huì)先把c賦給b再把b的值賦給aa ? b : c ? d : e會(huì)先解析后面的三目前面已經(jīng)提過(guò)。這張表還有個(gè)容易被忽略的點(diǎn)、^、|的優(yōu)先級(jí)低于和!但高于和||。這意味著判斷一個(gè)數(shù)的某個(gè)二進(jìn)制位是否為 1 時(shí)if (x 8 8)的真實(shí)解析順序是if (x (8 8))也就是x 1跟你想要的意思差了十萬(wàn)八千里。這種迷惑行為幾乎在每個(gè)季度都會(huì)出現(xiàn)在我們團(tuán)隊(duì)的代碼評(píng)審里。2.2 優(yōu)先級(jí)引發(fā)的真實(shí)翻車現(xiàn)場(chǎng)我來(lái)講幾個(gè)真實(shí)遇到過(guò)的翻車案例比背表有用得多。第一個(gè)和打架。有個(gè)同事寫權(quán)限判斷意圖是判斷flag的第 3 位是否為 1。他寫的是if (flag 0x04 0x04)。由于的優(yōu)先級(jí)高于實(shí)際變成了flag (0x04 0x04)即flag 1。如果flag是偶數(shù)這個(gè)表達(dá)式恒為 0權(quán)限判斷永遠(yuǎn)失敗。我當(dāng)時(shí)把代碼走查結(jié)果貼給他的時(shí)候他盯著看了十分鐘才反應(yīng)過(guò)來(lái)。這類 bug 編譯器不會(huì)報(bào)錯(cuò)邏輯上也看似合理只有走到線上才會(huì)暴露。第二個(gè)賦值與比較混淆。if (x computeValue())這種寫法在 C/C 里根本不會(huì)報(bào)錯(cuò)而且常常碰巧能用因?yàn)橹灰x值結(jié)果非零條件就為真。問(wèn)題是當(dāng)computeValue()返回 0 時(shí)條件為假分支不會(huì)執(zhí)行。你本來(lái)的意圖可能是if (x computeValue())但因?yàn)樯賹懸粋€(gè)等號(hào)整個(gè)程序的業(yè)務(wù)流程全變了。更可怕的是這種代碼在某些場(chǎng)景下測(cè)試通過(guò)、線上出錯(cuò)因?yàn)闇y(cè)試數(shù)據(jù)和線上數(shù)據(jù)分布不同。我現(xiàn)在養(yǎng)成了一個(gè)習(xí)慣任何涉及和模糊的代碼一律加括號(hào)或直接改寫結(jié)構(gòu)杜絕歧義。第三個(gè)三目運(yùn)算符嵌套。int result a b ? (a c ? a : c) : (b c ? b : c);這是我見(jiàn)過(guò)最精致的取最大值寫法。雖然它邏輯正確但讀代碼的人至少需要十秒鐘才能確認(rèn)它沒(méi)寫錯(cuò)。這就是優(yōu)先級(jí)特性和人腦解析能力的沖突。代碼首先是給人讀的其次才是給機(jī)器跑的。一個(gè)表達(dá)式如果讓你需要反復(fù)確認(rèn)優(yōu)先級(jí)說(shuō)明它已經(jīng)不合格了。2.3 實(shí)用策略用括號(hào)表達(dá)意圖既然優(yōu)先級(jí)這么容易埋雷我的經(jīng)驗(yàn)就八個(gè)字該用括號(hào)絕不省事。別把我知道優(yōu)先級(jí)當(dāng)成別人也知道優(yōu)先級(jí)的理由。在一個(gè)團(tuán)隊(duì)協(xié)作的項(xiàng)目里你的代碼會(huì)被各種經(jīng)驗(yàn)水平的人閱讀。用括號(hào)把意圖寫清楚不僅對(duì)別人負(fù)責(zé)更是對(duì)自己負(fù)責(zé)——因?yàn)槟懔芎笤倩貋?lái)看自己代碼時(shí)大概率也記不清當(dāng)時(shí)的優(yōu)先級(jí)心得了。我給出一個(gè)實(shí)操標(biāo)準(zhǔn)只要表達(dá)式里混用了三類以上運(yùn)算符或者包含、、^、|中的任意兩個(gè)就加括號(hào)。比如if ((flag 0x04) ! 0)、if ((a % 2) 0)、if ((x 0x0F) 0x0F)。這些括號(hào)在語(yǔ)義上不是必需的但在維護(hù)性上是必需的。另外用、||連接條件時(shí)我會(huì)給每個(gè)比較單元加括號(hào)if ((score 60) (score 90))。這樣即使未來(lái)某天有人給語(yǔ)言改了優(yōu)先級(jí)當(dāng)然這不可能代碼意圖也不會(huì)被誤解。這個(gè)習(xí)慣在很多大型開(kāi)源項(xiàng)目里也是主流風(fēng)格不是過(guò)分謹(jǐn)慎而是職業(yè)素養(yǎng)。3. if 語(yǔ)句條件分支里的設(shè)計(jì)思維3.1 從 if-else if-else 看分支篩選順序if是所有編程語(yǔ)言最先教你的流程控制語(yǔ)句但很多人學(xué)好幾年都寫不出健壯的分支邏輯。問(wèn)題往往不是語(yǔ)法而是分支順序的設(shè)計(jì)?？催@個(gè)經(jīng)典例子根據(jù)成績(jī)打印等級(jí)90 分以上優(yōu)秀80 到 90 良好60 到 80 及格60 以下不及格。新手最容易寫錯(cuò)的是邊界值比如 90 分到底算哪個(gè)檔如果你的代碼是if (score 90) printf(優(yōu)秀); else if (score 80) printf(良好); else if (score 60) printf(及格); else printf(不及格);這里的關(guān)鍵是分支條件的順序必須是從嚴(yán)格到寬松或者反過(guò)來(lái)說(shuō)后面的條件隱含了前面所有條件的取反。第二條score 80能執(zhí)行說(shuō)明第一條score 90為假所以實(shí)際區(qū)間是80 score 90。第 90 分被第一條截住了不會(huì)落到第二條里。這是一件好事但你必須清楚地知道順序本身就在表達(dá)邏輯。如果順序?qū)懛戳薸f (score 60) printf(及格); else if (score 80) printf(良好); // 永遠(yuǎn)執(zhí)行不到那 90 分也會(huì)被判成及格因?yàn)榈谝粋€(gè)條件就把它攔截了。這類 bug 之所以常見(jiàn)是因?yàn)閷懘a時(shí)腦子里想的是區(qū)間而if-else if實(shí)際表達(dá)的是逐級(jí)收縮的階梯。寫之前先在紙上把每個(gè)分支的真實(shí)區(qū)間算出來(lái)是我給所有新人的第一條建議。還有一種情況是條件重疊導(dǎo)致順序依賴比如會(huì)員折扣普通用戶 9 折VIP 用戶 8 折超級(jí)會(huì)員 7 折。如果先判斷普通用戶就出問(wèn)題了因?yàn)?VIP 也是普通用戶的一種。正確做法是先判斷最特殊的身份或者用更明確的包含關(guān)系。順序不是隨意排的它是業(yè)務(wù)優(yōu)先級(jí)在代碼里的投影。3.2 嵌套與早退控制條件復(fù)雜度嵌套if是另一類讓人頭疼的東西。三重、四重嵌套的代碼邏輯上可能完全正確但閱讀體驗(yàn)不亞于讀一篇沒(méi)有標(biāo)點(diǎn)的文章。我處理嵌套問(wèn)題的核心原則只有一個(gè)能早退就早退。早退early return/early exit是指在函數(shù)開(kāi)頭就把非法、異常、不適合繼續(xù)處理的情況全部攔截掉用return、break、continue或throw直接結(jié)束當(dāng)前單元讓主流程保持扁平?？催@個(gè)例子// 不推薦嵌套地獄 if (user ! NULL) { if (user-isActive) { if (orders ! NULL) { if (orders-count 0) { processOrder(orders); } else { log(no orders); } } else { log(orders null); } } else { log(inactive); } } else { log(user null); }同樣的邏輯用早退改寫if (user NULL) { log(user null); return; } if (!user-isActive) { log(inactive); return; } if (orders NULL) { log(orders null); return; } if (orders-count 0) { log(no orders); return; } processOrder(orders);后者在邏輯上一模一樣但閱讀負(fù)擔(dān)下降了一個(gè)量級(jí)。每個(gè)條件獨(dú)立成行錯(cuò)誤處理集中在前面主流程露在外面。這就是我常說(shuō)的把異常拋在入口把主路徑留給讀者。早退還有一層好處它天然消除了 else 的需求。你只需要寫不滿足就退出的分支剩下的就是主流程邏輯上不需要 else 來(lái)配對(duì)。這在業(yè)務(wù)代碼里非常實(shí)用尤其是判斷鏈特別多的時(shí)候。3.3 邏輯運(yùn)算符優(yōu)化條件德摩根定律與短路當(dāng)你用、||組合條件時(shí)有兩個(gè)工具必須熟練短路求值和德摩根定律。先看短路。if (list ! NULL list-size 0)中如果list是空指針前面的條件為假整個(gè)表達(dá)式的值已經(jīng)確定于是后面的list-size根本不會(huì)執(zhí)行。這就避免了空指針崩潰。反過(guò)來(lái)if (list NULL || list-size 0)中如果list確實(shí)是空指針條件立即為真后面的也不會(huì)執(zhí)行。利用短路求值把可能出錯(cuò)的訪問(wèn)放在安全判斷后面是 C/C 和 Java 里最基礎(chǔ)、也最重要的技巧。但要注意這個(gè)特性在部分語(yǔ)言里并不存在。比如在早期的 VB 里And、Or不保證短路。好在現(xiàn)代主流語(yǔ)言 C/C/Java/JavaScript/Python 的、||都實(shí)現(xiàn)了短路。Python 里雖然沒(méi)有但and、or同樣短路。再看德摩根定律!(A B)等價(jià)于!A || !B!(A || B)等價(jià)于!A !B。這在實(shí)際編碼中有個(gè)大用處當(dāng)你覺(jué)得一個(gè)否定條件讀起來(lái)別扭時(shí)把它改造成肯定條件。舉個(gè)例子。你要判斷不是用戶已登錄 且 是管理員直接寫if (!(loggedIn isAdmin))時(shí)大腦要同時(shí)解析括號(hào)、取反、與運(yùn)算。用德摩根定律改寫為if (!loggedIn || !isAdmin)含義完全一致但可讀性好得多。我在代碼評(píng)審里無(wú)數(shù)次建議別人做這種等價(jià)變形——不是為了炫技而是讓條件語(yǔ)句像一句自然語(yǔ)言一樣直接被讀懂。3.4 if 判斷中的常見(jiàn)坑這一節(jié)全是真金白銀每一種我都親眼見(jiàn)過(guò)它們?cè)谏a(chǎn)環(huán)境里造成故障?？右桓↑c(diǎn)數(shù)直接比較。if (sum 10.0)這種寫法在大多數(shù)情況下是不可靠的。因?yàn)?IEEE 754 浮點(diǎn)數(shù)存在精度誤差0.1 0.2并不精確等于0.3。如果業(yè)務(wù)確實(shí)需要判斷浮點(diǎn)值標(biāo)準(zhǔn)做法是判斷誤差是否在可接受范圍內(nèi)即if (fabs(sum - 10.0) 1e-9)。這一點(diǎn)在涉及金額計(jì)算時(shí)尤其致命——所以正經(jīng)的金融業(yè)務(wù)都要求用定點(diǎn)數(shù)或整數(shù)分來(lái)存儲(chǔ)金額而不是用浮點(diǎn)?？佣愋碗[式轉(zhuǎn)換。C/C 里比較有符號(hào)和無(wú)符號(hào)整數(shù)時(shí)編譯器會(huì)把有符號(hào)數(shù)轉(zhuǎn)成無(wú)符號(hào)數(shù)。如果a是int值是-1b是unsigned int值是1那么if (a b)的結(jié)果是真因?yàn)?1被轉(zhuǎn)換成了巨大的無(wú)符號(hào)數(shù)。JavaScript 的也存在大量隱式轉(zhuǎn)換比如5 5為真。這就是為什么現(xiàn)在的代碼規(guī)范往往推薦使用嚴(yán)格相等運(yùn)算符從根源上避免這種看似相等的問(wèn)題?？尤奄x值寫進(jìn)條件。前面已經(jīng)提過(guò)if (x 5)。很多編譯器現(xiàn)在會(huì)給出 warning但不少項(xiàng)目為了編譯速度直接忽略了 warning等于放任 bug 存活。如果必須寫賦值并檢查我建議風(fēng)格是if ((x getValue()) ! 0)用兩層括號(hào)明顯提示這里確實(shí)是賦值不是筆誤?？铀谋容^鏈的反直覺(jué)。if (a b c)在數(shù)學(xué)上是合法的在 C/C 里也能編譯但邏輯跟你想要的可能完全不同。它實(shí)際被解析成(a b) c即先比較a b得到一個(gè)布爾值0 或 1再拿這個(gè) 0/1 去和c比較大小。正確寫法必須是if (a b b c)。這個(gè)坑在 Python 里反而不存在因?yàn)?Python 原生支持鏈?zhǔn)奖容^a b c。4. switch一張?zhí)D(zhuǎn)表的自我修養(yǎng)4.1 switch 語(yǔ)法與 fall-through 的生死線switch是另一個(gè)流程控制的核心利器。它的基本形態(tài)大家都會(huì)寫switch (grade) { case A: printf(優(yōu)秀); break; case B: printf(良好); break; case C: printf(及格); break; default: printf(未知等級(jí)); break; }但它有個(gè)讓無(wú)數(shù)初學(xué)者甚至資深開(kāi)發(fā)翻車的機(jī)制fall-through即沒(méi)有break時(shí)會(huì)繼續(xù)執(zhí)行下一個(gè) case。很多人第一次寫 switch 時(shí)忘記在 case 末尾加break結(jié)果程序把后續(xù)所有 case 的代碼都執(zhí)行了一遍。實(shí)際上 fall-through 本身不是設(shè)計(jì)缺陷它在某些場(chǎng)景下反而很有用。比如多個(gè)值共享同一套處理邏輯switch (key) { case y: case Y: printf(確認(rèn)); break; case n: case N: printf(取消); break; }這種落空是有意設(shè)計(jì)的為了讓代碼表達(dá)兩種情況一樣處理。但在團(tuán)隊(duì)協(xié)作中這種寫法必須加注釋說(shuō)明// fall through否則后面維護(hù)的人可能以為這是 bug幫你補(bǔ)一個(gè)break從而改變?cè)羞壿?。具體到項(xiàng)目規(guī)范我一般要求沒(méi)有 break 的 case 語(yǔ)句必須顯式注釋。無(wú)注釋的 fall-through 一律視為錯(cuò)誤。4.2 switch 在不同語(yǔ)言里的長(zhǎng)相差異很多人在 C 語(yǔ)言里學(xué)完 switch 就以為天下通用其實(shí)不同語(yǔ)言之間差異很大踩坑點(diǎn)也完全不同。C/C/Javaswitch 的判斷值必須是整數(shù)兼容類型——整型、字符型、枚舉Java 還可以支持字符串較新版本。而且case必須是編譯期常量不能用變量case x:會(huì)直接編譯報(bào)錯(cuò)。C 還有一個(gè)陷阱在 switch 的某個(gè) case 里定義局部變量時(shí)如果跳過(guò)初始化直接跳進(jìn)另一個(gè) case可能觸發(fā)跳過(guò)變量初始化的編譯錯(cuò)誤。JavaScriptswitch 使用嚴(yán)格全等判斷不會(huì)做類型轉(zhuǎn)換。所以switch (5)中的 case5不會(huì)匹配因?yàn)橐粋€(gè)是字符串一個(gè)是數(shù)字。這在需要精確匹配的場(chǎng)景下是好事但習(xí)慣了其他語(yǔ)言的隱式轉(zhuǎn)換的話要注意別踩。Python根本沒(méi)有 switch 關(guān)鍵字。官方推薦的替代方案有好幾種最常用的是字典映射def handle_a(): return 處理A def handle_b(): return 處理B handlers { A: handle_a, B: handle_b, } result handlers.get(key, lambda: 未知 )()這種查表法在某些場(chǎng)景下甚至比 switch 更靈活——你可以動(dòng)態(tài)注冊(cè)、組合、傳遞函數(shù)。理解這一點(diǎn)對(duì)寫出符合 Python 風(fēng)格的代碼很有幫助。其實(shí)這也讓我意識(shí)到switch 的底層邏輯本質(zhì)是從常量到處理動(dòng)作的映射看清這一點(diǎn)無(wú)論語(yǔ)言怎么變化你的設(shè)計(jì)思路都不變。4.3 switch 適合什么場(chǎng)景和 if 的取舍switch 和 if 不是簡(jiǎn)單的替代關(guān)系各有各的最佳戰(zhàn)場(chǎng)。我的經(jīng)驗(yàn)判斷標(biāo)準(zhǔn)有兩條判斷條件是精確匹配還是范圍判定以及分支數(shù)量多不多。如果判斷條件是變量等于某個(gè)常量、分支超過(guò) 2 到 3 個(gè)優(yōu)先使用 switch。比如狀態(tài)機(jī)的狀態(tài)轉(zhuǎn)換、協(xié)議解析里的命令字分派、菜單命令處理都是 switch 的主場(chǎng)。它比分寫一長(zhǎng)串if (x 1) ... else if (x 2) ...清晰得多。如果判斷條件是范圍——比如成績(jī)區(qū)間、年齡分段、速度檔位——用 if-else if 更合適。因?yàn)?switch 的 case 是離散常量表達(dá)不了60 到 80 之間這樣的語(yǔ)義。如果強(qiáng)行用 switch你得把每一個(gè)可能的整數(shù)都列成 case完全是災(zāi)難。還有一個(gè)隱形因素編譯器優(yōu)化。C/C 編譯器在 case 值分布較密集時(shí)會(huì)把 switch 編譯成一張?zhí)D(zhuǎn)表jump table執(zhí)行時(shí)直接根據(jù)索引跳轉(zhuǎn)時(shí)間復(fù)雜度是 O(1)而 if-else 鏈?zhǔn)侵饌€(gè)比較最壞情況是 O(n)。雖然現(xiàn)在 CPU 分支預(yù)測(cè)很強(qiáng)大性能差異不一定能感知但在熱路徑高頻調(diào)用的代碼上switch 的確定性優(yōu)勢(shì)還是值得認(rèn)可的。如果 case 值分布特別稀疏比如 1、1000、100000編譯器可能生成二分查找或 if 鏈這時(shí) switch 就不一定比 if 有性能優(yōu)勢(shì)了。所以做取舍時(shí)先看語(yǔ)義再看數(shù)量最后才考慮優(yōu)化。順序反了寫出來(lái)的代碼就容易不倫不類。5. 綜合實(shí)戰(zhàn)把運(yùn)算符和分支語(yǔ)句組合成可控的流程5.1 實(shí)戰(zhàn)一成績(jī)等級(jí)判定中的 if 與 switch 邊界理論說(shuō)了這么多我用三個(gè)實(shí)戰(zhàn)案例把它們串起來(lái)。第一個(gè)案例是經(jīng)典的成績(jī)等級(jí)判定但我要故意暴露一個(gè)重新設(shè)計(jì)的過(guò)程。一個(gè)常見(jiàn)的寫法是用if判斷區(qū)間// C語(yǔ)言等級(jí)判定 if (score 90) { grade A; } else if (score 80) { grade B; } else if (score 70) { grade C; } else if (score 60) { grade D; } else { grade F; }這段代碼是正確的但有人會(huì)問(wèn)能不能用 switch 寫答案是——如果只有字符 A/B/C/D/F 這幾個(gè)等級(jí)需要處理可以把等級(jí)作為 switch 的輸入對(duì)等級(jí)進(jìn)行后續(xù)分派但從分?jǐn)?shù)推出等級(jí)這一步不適合 switch因?yàn)槟闶欠秶袛嗖皇蔷_匹配。這就是我前面說(shuō)的邊界if 負(fù)責(zé)把連續(xù)范圍映射到離散類別switch 負(fù)責(zé)對(duì)離散類別做分派。這兩個(gè)環(huán)節(jié)往往是串聯(lián)的先用 if 把連續(xù)數(shù)據(jù)分類再用 switch 按類執(zhí)行不同動(dòng)作。這個(gè)案例還帶出一個(gè)實(shí)用技巧把復(fù)雜判斷封裝成獨(dú)立的評(píng)分函數(shù)不要在業(yè)務(wù)邏輯里到處寫score 90這種裸條件。否則一旦等級(jí)規(guī)則變化你需要搜遍全項(xiàng)目逐個(gè)改。封裝成getGrade(score)之后規(guī)則變化只改這一個(gè)函數(shù)這就是條件語(yǔ)句的高內(nèi)聚技巧。5.2 實(shí)戰(zhàn)二閏年判斷——運(yùn)算符優(yōu)先級(jí)與邏輯組合驗(yàn)證第二個(gè)案例閏年判斷。它有一個(gè)完備的判定規(guī)則能被 4 整除但不能被 100 整除或者能被 400 整除。很多人第一次寫是逐個(gè)if拼// 不推薦的拼湊寫法 if (year % 4 0) { if (year % 100 0) { if (year % 400 0) { isLeap 1; } else { isLeap 0; } } else { isLeap 1; } } else { isLeap 0; }這段代碼邏輯上沒(méi)錯(cuò)但嵌套深度讓人看得頭疼。用邏輯運(yùn)算符直接組合規(guī)則int isLeap (year % 4 0 year % 100 ! 0) || (year % 400 0);一行搞定。注意這里的括號(hào)不是多余的的優(yōu)先級(jí)高于||即使不寫括號(hào)year % 4 0 year % 100 ! 0 || year % 400 0的解析結(jié)果和上面也一致。但我依然建議加括號(hào)因?yàn)樽x者需要一眼看出這是一個(gè)大條件分成兩個(gè)子條件而不是現(xiàn)場(chǎng)查優(yōu)先級(jí)。選這個(gè)案例是想展示運(yùn)算符的組合能力能把嵌套三層的邏輯壓成一行表達(dá)式且不損失可讀性。但前提是你對(duì)優(yōu)先級(jí)、短路、括號(hào)的使用都有把握。否則寧可多寫幾行if嵌套也不要寫成一行天才代碼——穩(wěn)定性和可維護(hù)性永遠(yuǎn)優(yōu)先于代碼行數(shù)的減半。5.3 實(shí)戰(zhàn)三用位掩碼配合 switch 做狀態(tài)機(jī)分派第三個(gè)案例是實(shí)際業(yè)務(wù)里很常用的組合位運(yùn)算符生成狀態(tài)switch 分派動(dòng)作。假設(shè)一個(gè)任務(wù)管理系統(tǒng)任務(wù)狀態(tài)用一個(gè) 8 位整數(shù)表示低 3 位分別是是否已提交是否已審核是否已發(fā)布#define FLAG_SUBMITTED 0x01 // 二進(jìn)制 001 #define FLAG_REVIEWED 0x02 // 二進(jìn)制 010 #define FLAG_PUBLISHED 0x04 // 二進(jìn)制 100 // 讀取三個(gè)狀態(tài)位組合成一個(gè) 0~7 的枚舉值 int state 0; if (task FLAG_SUBMITTED) state | 1; if (task FLAG_REVIEWED) state | 2; if (task FLAG_PUBLISHED) state | 4; switch (state) { case 0: // 草稿 break; case 1: // 已提交未審核 break; case 3: // 已提交并已審核未發(fā)布 break; case 7: // 全流程完成 break; default: // 其他非法或異常組合 break; }這個(gè)模式把多個(gè)開(kāi)關(guān)狀態(tài)組合統(tǒng)一成一個(gè)離散狀態(tài)值再交給 switch 做 O(1) 分派。在實(shí)際項(xiàng)目里權(quán)限管理、功能開(kāi)關(guān)、訂單狀態(tài)流轉(zhuǎn)都能看到這種寫法的變體。它的核心竅門是用位運(yùn)算把多維信息壓縮成一個(gè)標(biāo)量用 switch 把標(biāo)量的每個(gè)取值映射到清晰的業(yè)務(wù)動(dòng)作。要注意的是這種模式要求你對(duì)位運(yùn)算和狀態(tài)組合有清晰的定義case 3表示1 | 2 同時(shí)成立不會(huì)寫錯(cuò)但閱讀時(shí)必須能心算出二進(jìn)制組合。我會(huì)在代碼注釋里把每個(gè)關(guān)鍵組合的含義寫清楚降低后續(xù)維護(hù)成本。5.4 代碼走查用透明度原則排查流程控制 Bug最后聊一個(gè)方法論。面對(duì)流程控制相關(guān)的疑難 bug我的排查鏈路基本是固定的分享出來(lái)供參考。第一步確認(rèn)表達(dá)式求值順序。把可疑的條件表達(dá)式拆開(kāi)逐個(gè)確認(rèn)每個(gè)子表達(dá)式的值和類型。比如if (a b c)先查優(yōu)先級(jí)表確認(rèn)實(shí)際求值順序是a (b c)還是(a b) c。凡是看著對(duì)但運(yùn)行不對(duì)的條件九成是優(yōu)先級(jí)或類型隱式轉(zhuǎn)換問(wèn)題。這時(shí)加括號(hào)重寫往往 bug 就消失了。第二步確認(rèn)短路是否被觸發(fā)。如果條件里有或||要檢查前一個(gè)條件是否意外地讓后一個(gè)條件永遠(yuǎn)不執(zhí)行。一個(gè)典型例子判斷部門某個(gè)字段時(shí)if (dept ! null dept.name 研發(fā))本來(lái)沒(méi)問(wèn)題但如果dept在之前的代碼里被賦過(guò)一個(gè)非空但錯(cuò)誤的默認(rèn)值短路就不會(huì)觸發(fā)后面的判斷照樣執(zhí)行邏輯就悄悄變了。第三步確認(rèn)分支是否被順序截胡。把if-else if的每個(gè)分支真實(shí)區(qū)間列出來(lái)檢查有沒(méi)有區(qū)間被前面的更寬泛條件提前攔截。這是查看起來(lái)多余但實(shí)際上影響流程的最快方法。很多偶爾才出現(xiàn)的錯(cuò)誤其實(shí)就是邊界值落到了錯(cuò)誤的區(qū)間里。第四步做最小化復(fù)現(xiàn)。當(dāng)我看不出問(wèn)題時(shí)會(huì)把可疑代碼抽離成一個(gè)獨(dú)立小函數(shù)用固定的幾個(gè)測(cè)試輸入跑一遍。比如把score分別設(shè)成 89、90、91觀察輸出變化。這一步能快速驗(yàn)證到底是我對(duì)優(yōu)先級(jí)的理解錯(cuò)了還是業(yè)務(wù)規(guī)則本身就含糊。最后一個(gè)心得代碼透明度。我始終追求的是——一段代碼拿給任何有經(jīng)驗(yàn)的工程師看不需要跑起來(lái)就能讀懂它想做什么。運(yùn)算符和條件語(yǔ)句是程序流程里最基礎(chǔ)的兩塊磚但恰恰是這兩塊磚最能決定一個(gè)項(xiàng)目的代碼質(zhì)量是能跑還是能維護(hù)。所以值得花點(diǎn)時(shí)間把它們真正吃透。