為什么很多程序員不用switch？

送大家以下java學(xué)習(xí)資料

我曾經(jīng)接手過一份代碼，遇到過一個(gè)三十幾個(gè)if else套if else的模塊。

心理罵罵咧咧誰他喵寫的這玩意，然后開始review歷史。

大致情況是這樣的：第一個(gè)程序員寫下這段代碼時(shí)，只有兩個(gè)if else；后來開始逐漸加需求，先是一個(gè)、兩個(gè)，隨后量變引起質(zhì)變，于是邏輯分支快速擴(kuò)張。

這個(gè)時(shí)候已經(jīng)沒有人愿意去重構(gòu)成switch或是其他什么設(shè)計(jì)模式了，畢竟復(fù)雜度擺在那里，萬一崩了還得背鍋。

三四個(gè)程序員接手這段代碼之后，就變成我現(xiàn)在這種局面了。

第一個(gè)程序員絕對(duì)沒有料到這么簡單的邏輯在之后會(huì)變成這么復(fù)雜的模塊，甚至在增添第一第二條else時(shí)，也只是很隨意的加上。

所以我覺得，這個(gè)鍋絕對(duì)是是甲方的，讓他娘的隨便改需求。

這么一想心里就好受多了，編程嘛，最重要的是要看的開。

于是我又增加了兩條else，測試，提交，下班。

有時(shí)候真的不是我們不想寫好代碼，是不能寫好代碼。寫著寫著需求砍了、需求變了，什么設(shè)計(jì)模式都不頂用，最終還是怎樣快怎樣方便怎樣來，因?yàn)楦緵]人知道這段代碼還能不能活的過下一段需求變動(dòng)。

有的人肯定要說怎么不訂合同。合同肯定是有的，但是明明白紙黑字寫的合同，該改還是得改，畢竟你要是不同意甲方那些“微小的變動(dòng)”，以后還做不做了？！金主真能去得罪？

還是要學(xué)會(huì)得過且過，跟什么過不去也不能跟自己過不去，糟糕的代碼忍一忍就完了:代碼能跑、頭發(fā)不少，對(duì)我們這些打工的人而言比什么都重要。

現(xiàn)實(shí)工作絕不是課本中的理想狀態(tài)，會(huì)有無數(shù)的突發(fā)情況在等著你。你定義了半天觀察者、備忘錄，第二天這部分需求被砍了；寫了半天接口，抽象類，忽然下午告訴你要加個(gè)十萬八千里打不著邊的啥東西，于是又開始加適配器，等你加完了告訴你又砍了。甚至有次半夜被喊起來改代碼，等改完了發(fā)現(xiàn)需求被撤回了，氣的我直接請(qǐng)了兩天假調(diào)整心情。

設(shè)計(jì)模式和大的框架絕對(duì)是一個(gè)項(xiàng)目中非常重要的東西，但不是絕對(duì)重要的；一個(gè)好的PM團(tuán)隊(duì)，在某種意義上，才真正決定了這個(gè)項(xiàng)目的代碼質(zhì)量。[1]

請(qǐng)用5秒鐘的時(shí)間查看下面的代碼是否存在bug。

OK，熟練的程序猿應(yīng)該已經(jīng)發(fā)現(xiàn)Bug所在了，在第8行和第10行下面我沒有添加關(guān)鍵字break; 這就導(dǎo)致這段代碼的行為邏輯與我的設(shè)計(jì)初衷不符了。

缺點(diǎn)一. 語法正確，邏輯錯(cuò)誤

這就是第一個(gè)理由為什么程序猿很少使用switch來做條件判斷，對(duì)于新手來說忘記寫break實(shí)在是再普通不過了，就算是老猿忘記寫也是時(shí)有發(fā)生的事情，而這個(gè)語法錯(cuò)誤在諸多的語法檢查器上沒有辦法檢查出來的，因?yàn)閺恼Z法角度來說是正確的！可是代碼的處理邏輯卻是錯(cuò)誤的！用if來重寫這段代碼的話，就不會(huì)發(fā)生這種錯(cuò)誤。

上面的代碼為了保證正確我添加了else做一個(gè)邏輯上的保證，其實(shí)如果不寫else，這段代碼也不會(huì)發(fā)生邏輯錯(cuò)誤，而且一旦我忘記寫花括號(hào)的時(shí)候，語法編譯器是會(huì)提示我添加的，甚至可以使用eslint這種的工具強(qiáng)制我使用花括號(hào)，這樣就不會(huì)犯語法錯(cuò)誤了，一旦出現(xiàn)bug，那么肯定是我邏輯上的問題了。

缺點(diǎn)二 .死板的語法

switch盡管對(duì)于break很寬容，但是對(duì)判斷條件很嚴(yán)苛，case后面只能跟常量，如果你用C編寫的話，甚至只能用int類型作為判斷條件。對(duì)于我們這么瀟灑自如的程序猿來說，這種限制實(shí)在是太麻煩了，用if的話，別說是常量了，我用函數(shù)都可以，真正做到方便快捷。

缺點(diǎn)三 .需要子函數(shù)來處理分支

這個(gè)缺點(diǎn)跟缺點(diǎn)一有關(guān)，為了防止漏寫break，因此建議把分支處理方法獨(dú)立成一個(gè)子函數(shù)來處理，這樣在閱讀代碼的時(shí)候就會(huì)減少忘記寫break帶來的bug，那么用if來寫的話，我想怎么寫就怎么寫，非常隨意自由，但是這也導(dǎo)致了代碼的可讀性大大降低。

switch的優(yōu)點(diǎn)

既然switch有這么嚴(yán)重的缺點(diǎn)，那怎么在所有語言中依然會(huì)存在呢？那就說下switch的優(yōu)點(diǎn)吧，它的優(yōu)點(diǎn)也剛好是它的缺點(diǎn)。

在很久很久以前，那時(shí)候的電腦性能還不如一臺(tái)小霸學(xué)習(xí)機(jī)的時(shí)候，聰明的計(jì)算機(jī)科學(xué)家為了提高計(jì)算機(jī)的處理速度，將一些邏輯分支處理方法簡化了一下，把一些需要做邏輯判斷的操作給固定死，然后只要查表一樣一個(gè)一個(gè)對(duì)一下就能做出相應(yīng)的反應(yīng)了。

比如說a=0的判斷，switch和if在cpu上面的處理方式是不一樣的，switch是在編譯階段將子函數(shù)的地址和判斷條件綁定了，只要直接將a的直接映射到子函數(shù)地址去執(zhí)行就可以了，但是if處理起來就不一樣了。

它首先要把a(bǔ)的值放到CPU的寄存器中，然后要把比較的值放到CPU的另一個(gè)寄存器中，然后做減法，然后根據(jù)計(jì)算結(jié)果跳轉(zhuǎn)到子函數(shù)去執(zhí)行，這樣一來就要多出3步的操作了，如果邏輯判斷多的話，那么將會(huì)比switch多處許多倍的操作，盡管寄存器操作的速度很快，但是對(duì)于當(dāng)時(shí)的學(xué)習(xí)機(jī)來說，這點(diǎn)速度根本不夠用啊。

那還有一個(gè)問題，為什么要使用break來做一個(gè)判斷結(jié)束呢？這不是很容易造成語法錯(cuò)誤了？那就要說到子函數(shù)的問題上了。

在早起的電腦代碼中是沒有子函數(shù)的概念的，那時(shí)候都是用goto隨意跳轉(zhuǎn)的，你想去第10行代碼，很簡單goto 10就可以了。這種編程思維在C的早期階段還是一直受到影響的，因此早期的C也沒有子函數(shù)，都是一堆邏輯處理混亂在一起，goto滿天飛，所以那時(shí)候你沒有一個(gè)最強(qiáng)大腦是寫不了程序的。那為了告訴程序我這里條件判斷處理結(jié)束，就添加了break作為終止符號(hào)。后來慢慢的有了子程序，有了更好的編程規(guī)范，才一步一步的將寫代碼淪落到體力勞動(dòng)。

后來發(fā)展的新語言為了標(biāo)榜自己的血統(tǒng)，多少都要參考下C，然后就把switch這種詭異的語法也繼承下來了。但是也不是所有的語言都照搬，比如Google發(fā)明的新語言golang和kotlin就又把switch包裝了一下，去掉了令人誤會(huì)的語法，又讓switch變得靈活起來了，對(duì)了，在代碼重構(gòu)的時(shí)候，還是用switch把，這樣看起來的確代碼更簡潔哦！[2]