求求你們了,別再寫滿屏的 if/ else 了!

2021-03-02 Java愛好者

來自:CSDN,作者:yinnnnnnn

連結:https://blog.csdn.net/qq_35440678/article/details/7793999

為什麼我們寫的代碼都是 if-else?

程式設計師想必都經歷過這樣的場景:剛開始自己寫的代碼很簡潔,邏輯清晰,函數精簡,沒有一個 if-else,可隨著代碼邏輯不斷完善和業務的瞬息萬變:比如需要對入參進行類型和值進行判斷;這裡要判斷下對象是否為 null;不同類型執行不同的流程。

落地到具體實現只能不停地加 if-else 來處理,漸漸地,代碼變得越來越龐大,函數越來越長,文件行數也迅速突破上千行,維護難度也越來越大,到後期基本達到一種難以維護的狀態。

雖然我們都很不情願寫出滿屏 if-else 的代碼,可邏輯上就是需要特殊判斷,很絕望,可也沒辦法避免啊。

其實回頭看看自己的代碼,寫 if-else 不外乎兩種場景:異常邏輯處理和不同狀態處理。

兩者最主要的區別是:異常邏輯處理說明只能一個分支是正常流程,而不同狀態處理都所有分支都是正常流程。

怎麼理解?舉個例子:

 1//舉例一:異常邏輯處理例子
 2Object obj = getObj();
 3if (obj != null) {
 4    //do something
 5}else{
 6    //do something
 7}
 8
 9//舉例二:狀態處理例子
10Object obj = getObj();
11if (obj.getType == 1) {
12    //do something
13}else if (obj.getType == 2) {
14    //do something
15}else{
16    //do something
17}

第一個例子 if (obj != null) 是異常處理,是代碼健壯性判斷,只有 if 裡面才是正常的處理流程,else 分支是出錯處理流程;而第二個例子不管 type 等於 1,2 還是其他情況,都屬於業務的正常流程。對於這兩種情況重構的方法也不一樣。

代碼 if-else 代碼太多有什麼缺點?

缺點相當明顯了:最大的問題是代碼邏輯複雜,維護性差,極容易引發 bug。如果使用 if-else,說明 if 分支和 else 分支的重視是同等的,但大多數情況並非如此,容易引起誤解和理解困難。

是否有好的方法優化?如何重構?

方法肯定是有的。重構 if-else 時,心中無時無刻把握一個原則:

儘可能地維持正常流程代碼在最外層。

意思是說,可以寫 if-else 語句時一定要儘量保持主幹代碼是正常流程,避免嵌套過深。

實現的手段有:減少嵌套、移除臨時變量、條件取反判斷、合併條件表達式等。關注公眾號網際網路架構師可以獲取一份全套的 Java 架構視頻。

下面舉幾個實例來講解這些重構方法:

異常邏輯處理型重構方法實例一

重構前:

 1double disablityAmount(){
 2    if(_seniority < 2)
 3        return 0;
 4
 5    if(_monthsDisabled > 12)
 6        return 0;
 7
 8    if(_isPartTime)
 9        return 0;
10
11    //do somethig
12}

重構後:

1double disablityAmount(){
2    if(_seniority < 2 || _monthsDisabled > 12 || _isPartTime)
3        return 0;
4
5    //do somethig
6}

這裡的重構手法叫合併條件表達式:如果有一系列條件測試都得到相同結果,將這些結果測試合併為一個條件表達式。

這個重構手法簡單易懂,帶來的效果也非常明顯,能有效地較少if語句,減少代碼量邏輯上也更加易懂。

異常邏輯處理型重構方法實例二

重構前:

 1double getPayAmount(){
 2    double result;
 3    if(_isDead) {
 4        result = deadAmount();
 5    }else{
 6        if(_isSeparated){
 7            result = separatedAmount();
 8        }
 9        else{
10            if(_isRetired){
11                result = retiredAmount();
12            else{
13                result = normalPayAmount();
14            }
15        }
16    }
17    return result;
18}

重構後:

 1double getPayAmount(){
 2    if(_isDead)
 3        return deadAmount();
 4
 5    if(_isSeparated)
 6        return separatedAmount();
 7
 8    if(_isRetired)
 9        return retiredAmount();
10
11    return normalPayAmount();
12}

怎麼樣?比對兩個版本,會發現重構後的版本邏輯清晰,簡潔易懂。

和重構前到底有什麼區別呢?

最大的區別是減少 if-else 嵌套。可以看到,最初的版本 if-else 最深的嵌套有三層,看上去邏輯分支非常多,進到裡面基本都要被繞暈。其實,仔細想想嵌套內的 if-else 和最外層並沒有關聯性的,完全可以提取最頂層。

改為平行關係,而非包含關係,if-else 數量沒有變化,但是邏輯清晰明了,一目了然。

另一個重構點是廢除了 result 臨時變量,直接 return 返回。好處也顯而易見直接結束流程,縮短異常分支流程。原來的做法先賦值給 result 最後統一 return,那麼對於最後 return 的值到底是那個函數返回的結果不明確,增加了一層理解難度。

總結重構的要點:如果 if-else 嵌套沒有關聯性,直接提取到第一層,一定要避免邏輯嵌套太深。儘量減少臨時變量改用 return 直接返回。

異常邏輯處理型重構方法實例三

重構前:

1public double getAdjustedCapital(){
2    double result = 0.0;
3    if(_capital > 0.0 ){
4        if(_intRate > 0 && _duration >0){
5            resutl = (_income / _duration) *ADJ_FACTOR;
6        }
7    }
8    return result;
9}

第一步,運用第一招,減少嵌套和移除臨時變量:

1public double getAdjustedCapital(){
2    if(_capital <= 0.0 ){
3        return 0.0;
4    }
5    if(_intRate > 0 && _duration >0){
6        return (_income / _duration) *ADJ_FACTOR;
7    }
8    return 0.0;
9}

這樣重構後,還不夠,因為主要的語句 (_income / _duration) *ADJ_FACTOR; 在 if 內部,並非在最外層,根據優化原則(儘可能地維持正常流程代碼在最外層),可以再繼續重構:

 1public double getAdjustedCapital(){
 2    if(_capital <= 0.0 ){
 3        return 0.0;
 4    }
 5    if(_intRate <= 0 || _duration <= 0){
 6        return 0.0;
 7    }
 8
 9    return (_income / _duration) *ADJ_FACTOR;
10}

這才是好的代碼風格,邏輯清晰,一目了然,沒有 if-else 嵌套難以理解的流程。

這裡用到的重構方法是:將條件反轉使異常情況先退出,讓正常流程維持在主幹流程。

異常邏輯處理型重構方法實例四

重構前:

 1   /* 查找年齡大於18歲且為男性的學生列表 */
 2    public ArrayList<Student> getStudents(int uid){
 3        ArrayList<Student> result = new ArrayList<Student>();
 4        Student stu = getStudentByUid(uid);
 5        if (stu != null) {
 6            Teacher teacher = stu.getTeacher();
 7            if(teacher != null){
 8                ArrayList<Student> students = teacher.getStudents();
 9                if(students != null){
10                    for(Student student : students){
11                        if(student.getAge() > = 18 && student.getGender() == MALE){
12                            result.add(student);
13                        }
14                    }
15                }else {
16                    logger.error("獲取學生列表失敗");
17                }
18            }else {
19                logger.error("獲取老師信息失敗");
20            }
21        } else {
22            logger.error("獲取學生信息失敗");
23        }
24        return result;
25    }

典型的"箭頭型"代碼,最大的問題是嵌套過深,解決方法是異常條件先退出,保持主幹流程是核心流程:

重構後:

 1   /* 查找年齡大於18歲且為男性的學生列表 */
 2    public ArrayList<Student> getStudents(int uid){
 3        ArrayList<Student> result = new ArrayList<Student>();
 4        Student stu = getStudentByUid(uid);
 5        if (stu == null) {
 6            logger.error("獲取學生信息失敗");
 7            return result;
 8        }
 9
10        Teacher teacher = stu.getTeacher();
11        if(teacher == null){
12            logger.error("獲取老師信息失敗");
13            return result;
14        }
15
16        ArrayList<Student> students = teacher.getStudents();
17        if(students == null){
18            logger.error("獲取學生列表失敗");
19            return result;
20        }
21
22        for(Student student : students){
23            if(student.getAge() > 18 && student.getGender() == MALE){
24                result.add(student);
25            }
26        }
27        return result;
28    }

狀態處理型重構方法實例一

重構前:

 1double getPayAmount(){
 2    Object obj = getObj();
 3    double money = 0;
 4    if (obj.getType == 1) {
 5        ObjectA objA = obj.getObjectA();
 6        money = objA.getMoney()*obj.getNormalMoneryA();
 7    }
 8    else if (obj.getType == 2) {
 9        ObjectB objB = obj.getObjectB();
10        money = objB.getMoney()*obj.getNormalMoneryB()+1000;
11    }
12}

重構後:

 1double getPayAmount(){
 2    Object obj = getObj();
 3    if (obj.getType == 1) {
 4        return getType1Money(obj);
 5    }
 6    else if (obj.getType == 2) {
 7        return getType2Money(obj);
 8    }
 9}
10
11double getType1Money(Object obj){
12    ObjectA objA = obj.getObjectA();
13    return objA.getMoney()*obj.getNormalMoneryA();
14}
15
16double getType2Money(Object obj){
17    ObjectB objB = obj.getObjectB();
18    return objB.getMoney()*obj.getNormalMoneryB()+1000;
19}

這裡使用的重構方法是:把 if-else 內的代碼都封裝成一個公共函數。函數的好處是屏蔽內部實現,縮短 if-else 分支的代碼。代碼結構和邏輯上清晰,能一下看出來每一個條件內做的功能。

狀態處理型重構方法實例二

針對狀態處理的代碼,一種優雅的做法是用多態取代條件表達式(《重構》推薦做法)。

你手上有個條件表達式,它根據對象類型的不同而選擇不同的行為。將這個表達式的每個分支放進一個子類內的覆寫函數中,然後將原始函數聲明為抽象函數。

重構前:

 1double getSpeed(){
 2    switch(_type){
 3        case EUROPEAN:
 4            return getBaseSpeed();
 5        case AFRICAN:
 6            return getBaseSpeed()-getLoadFactor()*_numberOfCoconuts;
 7        case NORWEGIAN_BLUE:
 8            return (_isNailed)?0:getBaseSpeed(_voltage);
 9    }
10}

重構後:

 1class Bird{
 2    abstract double getSpeed();
 3}
 4
 5class European extends Bird{
 6    double getSpeed(){
 7        return getBaseSpeed();
 8    }
 9}
10
11class African extends Bird{
12    double getSpeed(){
13        return getBaseSpeed()-getLoadFactor()*_numberOfCoconuts;
14    }
15}
16
17class NorwegianBlue extends Bird{
18    double getSpeed(){
19        return (_isNailed)?0:getBaseSpeed(_voltage);
20    }
21}

可以看到,使用多態後直接沒有了 if-else,但使用多態對原來代碼修改過大,需要一番功夫才行。最好在設計之初就使用多態方式。關注公眾號網際網路架構師可以獲取架構視頻。

總結

if-else 代碼是每一個程式設計師最容易寫出的代碼,同時也是最容易被寫爛的代碼,稍不注意,就產生一堆難以維護和邏輯混亂的代碼。

針對條件型代碼重構把握一個原則:

儘可能地維持正常流程代碼在最外層,保持主幹流程是正常核心流程。

為維持這個原則:合併條件表達式可以有效地減少if語句數目;減少嵌套能減少深層次邏輯;異常條件先退出自然而然主幹流程就是正常流程。

針對狀態處理型重構方法有兩種:一種是把不同狀態的操作封裝成函數,簡短 if-else 內代碼行數;另一種是利用面向對象多態特性直接幹掉了條件判斷。

現在回頭看看自己的代碼,犯了哪些典型錯誤,趕緊運用這些重構方法重構代碼吧!!

分享程式設計師找工作經驗

程式設計師筆試、面試題

相關焦點

  • 求求你們了,別再寫滿屏的 if/ else 了
    為什麼我們寫的代碼都是 if-else?程式設計師想必都經歷過這樣的場景:剛開始自己寫的代碼很簡潔,邏輯清晰,函數精簡,沒有一個 if-else,可隨著代碼邏輯不斷完善和業務的瞬息萬變:比如需要對入參進行類型和值進行判斷;這裡要判斷下對象是否為 null;不同類型執行不同的流程。
  • 這滿屏的 if/ else,交接的兄弟快被逼瘋!
    為什麼我們寫的代碼都是 if-else?
  • 別再用Else語句寫代碼了!
    作者丨Joey Colon 譯者丨核子可樂 策劃丨小智 if…else 語句是許多程式設計師在寫代碼時最常用的方式之一。你甚至可以看到許多程式設計師的代碼中嵌套著無數 else 語句。可這樣,真的好嗎?
  • 求求你們別劇透!英語中「劇透」怎麼說?
    看到這裡,小夥伴你們知道劇透為何被稱作spoiler嗎?別讓他毀了你的晚上。• It's important not to let mistakes spoil your life.重要的是不要讓錯誤毀了你的生活。② 作為【嬌慣/寵壞】意思時✅指過度寵溺,溺愛,寵壞(孩子),表示到達一種程度。
  • 大學生支教漸漸「變味」, 農民:求求你們別來了,瞎費功夫
    說起知青這個詞,很多人都肅然起敬,畢竟這類人是大多是腳踏實地的前往一些落後地方接受再教育,他們與當地人一樣幹活,忘卻奢華城市的工作待遇和生活。為當地的農民起到模範作用,讓人們感受到城市與落後農村的距離並不遠。與此相近的還有一個詞那就是支教了,以前這個行為也是令人為之動容的,不過近些年的大學生支教卻漸漸「變味」。
  • 「C++ 篇」答應我,別再if/else走天下了可以嗎
    正文糟糕 if / else 連環if/else可以說是我們學習編程時,第一個學習的分支語句,簡單易理解,生活中也處處有的if/else例子看見賣西瓜的 )買一斤包子;else買一隻( 包子 );非常生生動動的生活例子!如果身為程式設計師的你,犯了同樣的思維錯誤,別繼續問你媳婦為什麼,問就是跪鍵盤:進入本文正題。
  • 只會用if,else寫代碼?該換一種簡單高效的方式了!
    在寫代碼的過程中,用得最多的語句大概就是if,else了,這個語句堪稱萬能語句,能滿足絕大多數需求。但是如果太多的if,else嵌套,你還會去選擇使用它嗎?本文推薦一種可以代替if,else語句的寫法-衛語句,讓你的代碼運行更高效別再用if,else寫代碼了!高效語句你值得擁有!
  • CTO:再寫if-else,逮著罰款1000!
    Simple if-else只需刪除 else` 塊即可簡化此過程,如下圖:Removed else看起來更專業吧?你會發現,實際上根本不需要其他塊。像在這種情況下一樣,你想要在滿足特定條件的情況下執行某些操作並立即返回。
  • 懷舊服:求求你們面對現實吧
    懷舊服:求求你們面對現實吧
  • 求求你們別秀了,打遊戲聽這幾首音樂,絕對讓你五殺超神
    求求你們別秀了,打遊戲聽這幾首音樂,絕對讓你五殺超神我們的娛樂活動除了逛街購物看電影,沒事的時候還喜歡打打遊戲,在打遊戲的時候我們有時候選擇聽一些歌曲。聽歌讓我們打遊戲的時候更加的精神,有時候仿佛聽著一首歌,你就像那最無敵的人一樣,戰無不勝,攻無不克。
  • 22歲姐姐拒養2歲弟弟被起訴:無良父母,求求你們別再生了
    在當時父母要生二胎的時候,姐姐就非常的反對,當時她就說:憑什麼要我養弟弟,你們就是告我,我也不養。她實在是不理解為什麼明明養不起,為什麼卻還是要生的父母。最後父母把女兒告上法庭,父母勝訴。3求求你們,養不起就別生了!每個月給一筆錢,雖然數額不多,但對一個剛進入社會的女孩子來說,無疑是一個負擔。而且,如果父母去世了,姐姐要做的就不止是扶養義務,她還要成為弟弟的監護人。
  • 求求你,以後千萬別惹郭霄漢這個單身老男人!嘲笑沒金V的注意了!
    迷惑了就對了,下面就讓大田田給你們說道說道具體是怎麼一回事吧!求求你,以後千萬別惹郭霄漢這個單身老男人!嘲笑沒金V的注意了郭霄漢不找對象是因為忙著記仇吧?千萬別惹這個單身老男人!你們見過的最記仇的人是什麼樣的呢?有句話說得好,君子報仇,十年不晚。這句話在此送給老漢了。首先,給大家看一張圖片吧!好了,不要激動,也不要迷惑,這個照片就是我們最最最親愛的老漢的記仇本呢,看看,仔細看看,你們的微博名字有沒有出現在上面呢!
  • 一家三口組隊「啃老」,7旬老人無奈落淚:求求你們別來看我了!
    原本夫妻倆的退休金照顧自己綽綽有餘,不需要兒子兒媳再承擔什麼,現在一家三口在老兩口這裡吃住,老王夫妻倆的退休金被用得所剩無幾,已經年過七旬老人最終無奈落淚:求求你們別再來看我了!其實在我們身邊,這樣的啃老族還有很多,孩子之所以變成這樣,其實跟家長的失敗教育有很大的關係。
  • 沒人比我更懂if-else和switch-case
    }呃,突然覺得當程式設計師,好操心……以上,用if-else繼續寫下去,你可能會抓狂。這個不是寫代碼的錯,而且一開始就要做好程序設計,想好要用什麼模式或者模型來實現這個過程。要不試試面向對象?哈哈哈!扯遠了,講真,寫if真的別忘了else,即使你真的不需要else,但你也別忘了!
  • 地瓜熊老六:方方,求求你,不要再罵中國老百姓了
    昨天,方方的日記,特意咬著後槽牙,惡狠狠地寫了兩大段:特別想要感謝那些天天圍攻我的極左分子。沒有他們的激勵,像我這樣懶散的人,或許早就不寫了,也或許三天打漁兩天曬網,寫不了這許多。而我這樣的信手拈來的記錄,又會有多少人去看呢?尤其讓我高興的是,他們此番對我的攻擊,幾乎拼出了全部家底。集結了他們所有的隊伍,差不多每個人都寫了文章。但是讀者們看到的是什麼?
  • 求求你們,別再燙「蛋卷頭」了!
    所以,為了避免這些得不償失的情況,大家在挑選髮型時可別忘了要綜合自己的情況去考慮和選擇哦!好啦,本期的分享就到這裡,大家認為還有哪些人不適合燙蛋卷頭呢?歡迎在評論區留言補充、提醒,我們下期再見!
  • 超模肯豆:流水的緋聞男友,鐵打的fai仔,求求你們在一起吧!
    在這麼美的畫面裡,我的眼裡只有你,感覺到超級浪漫呢,粉絲也表示求求你們在一起吧!不過兩個人目前只是朋友啦, 但在一起的畫面就像是熱戀的情侶,粉絲就跟看偶像劇一樣,太甜啦!超模肯豆:流水的緋聞男友,鐵打的fai仔,求求你們在一起吧!
  • 如何在 react 中使用 if-elseif-else 多重條件判斷
    `您一共有${list..length}條數據` : '您暫時還沒有數據'}</div>1.3 立即執行或者單獨的方法渲染當需要更複雜的判斷時,例如 3 個及以上的情況,或者多個判斷條件時,即if-elseif-else的類型時,情況就稍微複雜一些。不過我們依然也有多種方式來實現。
  • 編程技巧: 重構 if...else if...else...
    ,則倒是其次,主要連注釋寫的都很少。面對這樣的已經上線的代碼,我並沒有想去重構他因為成本太高,只好鞭策自己不要寫出這種代碼面對的問題?有時候,我們可能面對這樣的業務邏輯(教育類公司),如果是回答過題目通過,如果回答過題目沒有通過,如果沒有回答過題目。如果不使用特定的模式,可能會寫出下面這樣的代碼。一坨一坨的 if...else 看著非常不舒服,並且難以維護。
  • 如果你們ADC太菜?請注意一下輔助,ADC:求求你,去中單吧
    如果你們ADC太菜?請注意一下輔助,ADC:求求你,去中單吧在英雄聯盟裡,看一個ADC玩家水平就在於補刀了,但當你看到你家ADC的補刀10分鐘只有30刀的時候,請不要震驚,因為你們輔助10分鐘可能有70刀的補刀數,ADC:求求你去打中單吧,那咱們就來看一看哪些輔助是最讓ADC害怕的吧。