只要程式碼保持了足夠的可讀性就沒什麼不好的 if-else代表了邏輯的複雜度 雖然多了可讀性差 但有時候卻是最直觀反應業務邏輯的方法 有時候你封裝得死死的 別人一接手就瞎蒙屄了。我個人的經驗是，如果你沒有足夠優秀的組織架構能力，就老老實實的寫if-else吧，挺好的。

主要就這一個問題不好維護，除非寫的很爛執行了大量重複無用的判斷才可能有一丟丟效率問題。

如果三五個分支判斷，我覺得if-else挺好用的

除非可預見的動態擴充套件條件或者大量的或多級深度的判斷，考慮使用設計模式，否則還是if_else更加直觀和高效。至於那些言必稱優雅的還是先了解清楚什麼才是真正的優雅實現。就個人所知優雅一詞最早現於C++，是形容程式設計思想和精妙的演算法，而非弄些語法糖就大談優雅，如果有看過C++標準模板庫的原始碼實現，就能真正理解何為優雅。

主要就是可讀性差，不好維護。

不要小看可讀性啊，有的時候巢狀太多，過一段時間自己都看不懂了，這多煩人？

雖然說最終仔細看還是能看的懂，但是消耗時間啊，程式設計畢竟是個工作，時間就是效率。

可讀性差就好比是寫字寫的很潦草，雖然說寫字寫的潦草，並不代表你文章寫的不好，但是這真心不是什麼值得自豪的事情，也不值得推薦，寫文章畢竟還是要給別人看的，還是要寫的好看一些。

況且，程式設計是個不斷學習的過程，世界上沒有一個程式設計師敢說自己啥都懂不需要學習了。在寫程式的時候，嘗試用非迴圈的方式解決問題，也能不斷鍛鍊你演算法的能力。

至於效率問題，這個要具體問題具體分析，如果if-else設計不合理，當然會降低效率啊，當然這不是說用了if-else就一定效率低，主要還是看是什麼演算法。

比如說，設計一個許可權判斷的程式，我們可以用一個8位二進位制數來表示許可權，某一位賦值為1就表示有許可權，0表示沒有許可權。

這樣每次判斷許可權的時候，只需要把許可權和使用者實際的許可權數進行按位與運算，就可以判斷是否具有該許可權。

這樣設計，無論是可讀性，效率，都比寫十幾個不同的判斷好。

總之，養成透過演算法避免判斷過多的演算法，有百利無一害。唯一的害處可能是需要你動腦子去思考。

我覺得對程式執行的效率影響不大吧，要讓程式碼更加優雅主要還是設計要做好。然而使用者的需求經常會變更，和設計之初有差異，很多時候if else是不可避免的（聽說華為的程式碼也是一堆if else還有百度自動駕駛的程式碼），只要不死迴圈，對程式執行效率還好，畢竟使用者才是第一位，重點還是要滿足使用者的需求。

程式碼裡有if-else分支是很正常的，但結構化程式設計的觀點，是不要巢狀太深，以少於3層為限，多於這個幅度，編寫和閱讀理解的難度是指數式上升。當邏輯需要巢狀的時候，需要考慮重構這部分程式碼，有兩種方法。一是犧牲效率，把巢狀的部分分拆成多個過程依次執行，書寫時用空行把這些部分隔開求清晰。二是把內嵌部分寫成函式，用有意義的能描述功能的函式命名取代，這樣分層閱讀和理解都輕鬆許多。推薦的做法是第二種，在當今最佳化編譯器和最佳化直譯器的環境，這類程式碼往往是可以編譯為內聯（inline）的，不會犧牲效率。

你問了兩個問題。

第一個問題的答案如下：

電腦本身對大量的if-else分支毫不在意。然而， 對於閱讀或者維護程式碼的人類來說，程式碼中充斥大量的if-else分支，導致程式碼難讀，難懂，難維護，難修改，易出現邏輯錯誤等。換一句話說，正確性、可維護性堪憂，可靠性堪憂。

針對性對策是重構程式碼，消滅if-else分支。

舉一個例子, 一個用Haskell實現的一個函式。給定一個數，大於0則返回1，等於0返回0，小於0則返回-1。

重構函式如下：

透過重構，利用Haskell的模式匹配，去除了巢狀if-else分支。程式碼變得簡單，易懂。越簡單的程式碼，越容易理解，讀懂，出錯的機率越低。

第二個問題的答案如下：

對於程式執行效率，沒有顯著的負面影響。我們知道，程式碼終將被編譯成電腦能懂得二進位制機器碼。if-else分支在組合語言層面無非就是一些跳轉。對於電腦而言，這些跳轉並不“昂貴”。

不好說，首先，這是相當主觀的一種判斷，但直觀上這對於堆疊溢位不是很理想的。使用長if / else語句，巢狀ifs等的程式有時難以維護，而且並不總是可讀性強，最好的方法是可以將long if語句替換為單獨的函式，從而更易於維護。

譬如編寫一個簡單的井字棋遊戲：

這段程式碼稱不上完美，甚至還不能說是很優的程式碼，但你可以看到它如何使你減少程式碼中if語句的數量，再進一步思考：

這使程式碼行具有不同的長度，同時減少了if語句；

最終，所有辦法都是殊路同歸，目的是儘量減少if語句，還可以（一種更好的方法做到檢查連續元素的相等性）：