1. 程式人生 > >為什麽程序員都不喜歡使用switch而使用if來做條件跳轉

為什麽程序員都不喜歡使用switch而使用if來做條件跳轉

image targe bsp 常量 article rec fec 語法錯誤 跳轉

請用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把,這樣看起來的確代碼更簡潔哦。

擴展閱讀

減少該死的 if else 嵌套

使用hexo+github搭建免費個人博客詳細教程

Git使用教程:最詳細、最傻瓜、最淺顯、真正手把手教!

為什麽前後端分離了,你比從前更痛苦?

為什麽不應該重寫service方法?

來源:http://dy.163.com/v2/article/detail/E02RDE6C0511SDDL.html

為什麽程序員都不喜歡使用switch而使用if來做條件跳轉