為什麼程式設計師都不喜歡使用switch，而是大量的 if……else if ？
作者：熊爸爸
原文：http://3g.163.com/tech/article/E02RDE6C0511SDDL.html
請用5秒鐘的時間檢視下面的程式碼是否存在bug。
OK，熟練的程式猿應該已經發現Bug所在了，在第8行和第10行下面我沒有新增關鍵字break; 這就導致這段程式碼的行為邏輯與我的設計初衷不符了。
缺點一. 語法正確，邏輯錯誤
這就是第一個理由為什麼程式猿很少使用switch來做條件判斷，對於新手來說忘記寫break實在是再普通不過了，就算是老猿忘記寫也是時有發生的事情，而這個語法錯誤在諸多的語法檢查器上沒有辦法檢查出來的，因為從語法角度來說是正確的！可是程式碼的處理邏輯卻是錯誤的！用if來重寫這段程式碼的話，就不會發生這種錯誤。
上面的程式碼為了保證正確我添加了else做一個邏輯上的保證，其實如果不寫else，這段程式碼也不會發生邏輯錯誤，而且一旦我忘記寫花括號的時候，語法編譯器是會提示我新增的，甚至可以使用eslint這種的工具強制我使用花括號，這樣就不會犯語法錯誤了，一旦出現bug，那麼肯定是我邏輯上的問題了。
缺點二 .死板的語法
switch儘管對於break很寬容，但是對判斷條件很嚴苛，case後面只能跟常量，如果你用C編寫的話，甚至只能用int型別作為判斷條件。對於我們這麼瀟灑自如的程式猿來說，這種限制實在是太麻煩了，用if的話，別說是常量了，我用函式都可以，真正做到方便快捷。
缺點三 .需要子函式來處理分支
這個缺點跟缺點一有關，為了防止漏寫break，因此建議把分支處理方法獨立成一個子函式來處理，這樣在閱讀程式碼的時候就會減少忘記寫break帶來的bug，那麼用if來寫的話，我想怎麼寫就怎麼寫，非常隨意自由，但是這也導致了程式碼的可讀性大大降低。
switch的優點
既然switch有這麼嚴重的缺點，那怎麼在所有語言中依然會存在呢？那就說下switch的優點吧，它的優點也剛好是它的缺點。
在很久很久以前，那時候的電腦效能還不如一臺小霸學習機的時候，聰明的電腦科學家為了提高計算機的處理速度，將一些邏輯分支處理方法簡化了一下，把一些需要做邏輯判斷的操作給固定死，然後只要查表一樣一個一個對一下就能做出相應的反應了。
比如說a=0的判斷，switch和if在cpu上面的處理方式是不一樣的，switch是在編譯階段將子函式的地址和判斷條件綁定了，只要直接將a的直接對映到子函式地址去執行就可以了，但是if處理起來就不一樣了，它首先要把a的值放到CPU的暫存器中，然後要把比較的值放到CPU的另一個暫存器中，然後做減法，然後根據計算結果跳轉到子函式去執行，這樣一來就要多出3步的操作了，如果邏輯判斷多的話，那麼將會比switch多處許多倍的操作，儘管暫存器操作的速度很快，但是對於當時的學習機來說，這點速度根本不夠用啊。
那還有一個問題，為什麼要使用break來做一個判斷結束呢？這不是很容易造成語法錯誤了？那就要說到子函式的問題上了。
在早起的電腦程式碼中是沒有子函式的概念的，那時候都是用goto隨意跳轉的，你想去第10行程式碼，很簡單goto 10就可以了。這種程式設計思維在C的早期階段還是一直受到影響的，因此早期的C也沒有子函式，都是一堆邏輯處理混亂在一起，goto滿天飛，所以那時候你沒有一個最強大腦是寫不了程式的。那為了告訴程式我這裡條件判斷處理結束，就添加了break作為終止符號。後來慢慢的有了子程式，有了更好的程式設計規範，才一步一步的將寫程式碼淪落到體力勞動。
後來發展的新語言為了標榜自己的血統，多少都要參考下C，然後就把switch這種詭異的語法也繼承下來了。但是也不是所有的語言都照搬，比如Google發明的新語言golang和kotlin就又把switch包裝了一下，去掉了令人誤會的語法，又讓switch變得靈活起來了，對了，在程式碼重構的時候，還是用switch把，這樣看起來的確程式碼更簡潔哦。