如何重構“箭頭型”代碼

文章有點長，我在文章最後會給出相關的思考和總結陳詞，你可以跳到結尾。

所謂箭頭型代碼，基本上來說就是下面這個圖檔所示的情況。

那麼，這樣“箭頭型”的代碼有什麼問題呢？看上去也挺好看的，有對稱美。但是……

關于箭頭型代碼的問題有如下幾個：

1）我的顯示器不夠寬，箭頭型代碼縮進太狠了，需要我來回拉水準滾動條，這讓我在讀代碼的時候，相當的不舒服。

2）除了寬度外還有長度，有的代碼的<code>if-else</code>裡的<code>if-else</code>裡的<code>if-else</code>的代碼太多，讀到中間你都不知道中間的代碼是經過了什麼樣的層層檢查才來到這裡的。

總而言之，“箭頭型代碼”如果嵌套太多，代碼太長的話，會相當容易讓維護代碼的人（包括自己）迷失在代碼中，因為看到最内層的代碼時，你已經不知道前面的那一層一層的條件判斷是什麼樣的，代碼是怎麼運作到這裡的，是以，箭頭型代碼是非常難以維護和Debug的。

OK，我們先來看一下微網誌上的那個示例，代碼量如果再大一點，嵌套再多一點，你很容易會在條件中迷失掉（下面這個示例隻是那個“大箭頭”下的一個小箭頭）

<code>FOREACH(Ptr<WfExpression>, argument, node->arguments) {</code>

<code></code><code>int</code> <code>index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());</code>

<code></code><code>if</code> <code>(index != -1) {</code>

<code></code><code>auto</code> <code>type = manager->expressionResolvings.Values()[index].type;</code>

<code></code><code>if</code> <code>(! types.Contains(type.Obj())) {</code>

<code></code><code>types.Add(type.Obj());</code>

<code></code><code>if</code> <code>(</code><code>auto</code> <code>group = type->GetTypeDescriptor()->GetMethodGroupByName(L</code><code>"CastResult"</code><code>,</code><code>true</code><code>)) {</code>

<code></code><code>int</code> <code>count = group->GetMethodCount();</code>

<code></code><code>for</code> <code>(</code><code>int</code> <code>i = 0; i < count; i++) {</code><code>auto</code> <code>method = group->GetMethod(i);</code>

<code></code><code>if</code> <code>(method->IsStatic()) {</code>

<code></code><code>if</code> <code>(method->GetParameterCount() == 1 &&</code>

<code></code><code>method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&</code>

<code></code><code>method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<</code><code>void</code><code>>() ) {</code>

<code></code><code>symbol->typeInfo = CopyTypeInfo(method->GetReturn());</code>

<code></code><code>break</code><code>;</code>

上面這段代碼，可以把條件反過來寫，然後就可以把箭頭型的代碼解掉了，重構的代碼如下所示：

<code></code><code>if</code> <code>(index == -1)</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( types.Contains(type.Obj()))</code><code>continue</code><code>;</code>

<code></code><code>auto</code> <code>group = type->GetTypeDescriptor()->GetMethodGroupByName(L</code><code>"CastResult"</code><code>,</code><code>true</code><code>);</code>

<code></code><code>if</code> <code>( ! group )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>(! method->IsStatic())</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( method->GetParameterCount() == 1 &&</code>

這種代碼的重構方式叫 Guard Clauses

這裡的思路其實就是，讓出錯的代碼先傳回，前面把所有的錯誤判斷全判斷掉，然後就剩下的就是正常的代碼了。

1.近期整理了20G資源，包含産品/營運/測試/程式員/市場等，網際網路從業者【工作必備幹貨技巧、行業專業書籍、面試真題寶典等】，擷取方式：

微信掃碼關注公衆号“非典型網際網路”，轉發文章到朋友圈，截圖發至公衆号背景，即可擷取幹貨資源連結；

2.網際網路人交流群：

關注公衆号“非典型網際網路”，在公衆号背景回複“入群”，人脈共享，一起交流；

微網誌上有些人說，continue 語句破壞了閱讀代碼的通暢，我覺得他們一定沒有好好讀這裡面的代碼，其實，我們可以看到，所有的 if 語句都是在判斷是否出錯的情況，是以，在維護代碼的時候，你可以完全不理會這些 if 語句，因為都是出錯處理的，而剩下的代碼都是正常的功能代碼，反而更容易閱讀了。當然，一定有不是上面代碼裡的這種情況，那麼，不用continue ，我們還能不能重構呢？

當然可以，抽成函數：

<code>bool</code> <code>CopyMethodTypeInfo(</code><code>auto</code> <code>&method,</code><code>auto</code> <code>&group,</code><code>auto</code> <code>&symbol)</code>

<code></code><code>if</code> <code>(! method->IsStatic()) {</code>

<code></code><code>return</code> <code>true</code><code>;</code>

<code></code><code>return</code> <code>false</code><code>;</code>

<code>void</code> <code>ExpressionResolvings(</code><code>auto</code> <code>&manager,</code><code>auto</code> <code>&argument,</code><code>auto</code> <code>&symbol)</code>

<code></code><code>if</code> <code>(index == -1)</code><code>return</code><code>;</code>

<code></code><code>if</code> <code>( types.Contains(type.Obj()))</code><code>return</code><code>;</code>

<code></code><code>if</code> <code>( ! group )</code><code>return</code><code>;</code>

<code></code><code>if</code> <code>( ! CopyMethodTypeInfo(method, group, symbol) )</code><code>break</code><code>;</code>

<code></code><code>ExpressionResolvings(manager, arguments, symbol)</code>

你發出現，抽成函數後，代碼比之前變得更容易讀和更容易維護了。不是嗎？

有人說：“如果代碼不共享，就不要抽取成函數！”，持有這個觀點的人太死讀書了。函數是代碼的封裝或是抽象，并不一定用來作代碼共享使用，函數用于屏蔽細節，讓其它代碼耦合于接口而不是細節實作，這會讓我們的代碼更為簡單，簡單的東西都能讓人易讀也易維護。這才是函數的作用。

微網誌上還有人問，原來的代碼如果在各個 if 語句後還有要執行的代碼，那麼應該如何重構。比如下面這樣的代碼。

原版

<code></code><code>do_before_cond1()</code>

<code></code><code>do_before_cond2();</code>

<code></code><code>do_before_cond3();</code>

<code></code><code>do_something();</code>

<code></code><code>do_after_cond3();</code>

<code></code><code>do_after_cond2();</code>

<code></code><code>do_after_cond1();</code>

上面這段代碼中的那些 <code>do_after_condX()</code> 是無論條件成功與否都要執行的。是以，我們拉平後的代碼如下所示：

重構第一版

<code></code><code>do_before_cond1();</code>

<code></code><code>continue</code>

<code></code><code>continue</code><code>;</code>

你會發現，上面的 <code>do_after_condX</code> 出現了兩份。如果 if 語句塊中的代碼改變了某些<code>do_after_condX</code>依賴的狀态，那麼這是最終版本。

但是，如果它們之前沒有依賴關系的話，根據 DRY 原則，我們就可以隻保留一份，那麼直接掉到 if 條件前就好了，如下所示：

重構第二版

<code></code><code>if</code> <code>( !cond1 )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( !cond2 )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( !cond3 )</code><code>continue</code><code>;</code>

此時，你會說，我靠，居然，改變了執行的順序，把條件放到 <code>do_after_condX()</code> 後面去了。這會不會有問題啊？

其實，你再分析一下之前的代碼，你會發現，本來，cond1 是判斷 do_before_cond1() 是否出錯的，如果有成功了，才會往下執行。而 do_after_cond1() 是無論如何都要執行的。從邏輯上來說，do_after_cond1()其實和do_before_cond1()的執行結果無關，而 cond1 卻和是否去執行 do_before_cond2() 相關了。如果我把斷行變成下面這樣，反而代碼邏輯更清楚了。

重構第三版

<code></code><code>if</code> <code>( !cond1 )</code><code>continue</code><code>;</code><code>// <-- cond1 成了是否做第二個語句塊的條件</code>

<code></code><code>if</code> <code>( !cond2 )</code><code>continue</code><code>;</code><code>// <-- cond2 成了是否做第三個語句塊的條件</code>

<code></code><code>if</code> <code>( !cond3 )</code><code>continue</code><code>;</code><code>//<-- cond3 成了是否做第四個語句塊的條件</code>

于是乎，在未來維護代碼的時候，維護人一眼看上去就明白，代碼在什麼時候會執行到哪裡。這個時候，你會發現，把這些語句塊抽成函數，代碼會幹淨的更多，再重構一版：

重構第四版

<code></code><code>return</code> <code>cond3;</code>

<code></code><code>return</code> <code>cond2;</code>

<code></code><code>return</code> <code>cond1;</code>

<code>// for-loop 你可以重構成這樣</code>

<code></code><code>if</code> <code>(cond) do_something();</code>

<code>// for-loop 也可以重構成這樣</code>

<code></code><code>if</code> <code>( ! do_func1() )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( ! do_func2() )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( ! do_func3() )</code><code>continue</code><code>;</code>

上面，我給出了兩個版本的for-loop，你喜歡哪個？我喜歡第二個。這個時候，因為for-loop裡的代碼非常簡單，就算你不喜歡 continue ，這樣的代碼閱讀成本已經很低了。

接下來，我們再來看另一個示例。下面的代碼的僞造了一個場景——把兩個人拉到一個一對一的聊天室中，因為要檢查雙方的狀态，是以，代碼可能會寫成了“箭頭型”。

<code>int</code> <code>ConnectPeer2Peer(Conn *pA, Conn* pB, Manager *manager)</code>

<code></code><code>if</code> <code>( pA->isConnected() ) {</code>

<code></code><code>manager->Prepare(pA);</code>

<code></code><code>if</code> <code>( pB->isConnected() ) {</code>

<code></code><code>manager->Prepare(pB);</code>

<code></code><code>if</code> <code>( manager->ConnectTogther(pA, pB) ) {</code>

<code></code><code>pA->Write(</code><code>"connected"</code><code>);</code>

<code></code><code>pB->Write(</code><code>"connected"</code><code>);</code>

<code></code><code>return</code> <code>S_OK;</code>

<code></code><code>return</code> <code>S_ERROR;</code>

<code></code><code>pA->Write(</code><code>"Peer is not Ready, waiting..."</code><code>);</code>

<code></code><code>return</code> <code>S_RETRY;</code>

<code></code><code>manager->Prepare();</code>

<code></code><code>pB->Write(</code><code>"Peer is not Ready, waiting..."</code><code>);</code>

<code></code><code>pA->Close();</code>

<code></code><code>pB->Close();</code>

<code></code><code>//Shouldn't be here!</code>

重構上面的代碼，我們可以先分析一下上面的代碼，說明了，上面的代碼就是對 PeerA 和 PeerB 的兩個狀态 “連上”， “未連上” 做組合 “狀态” （注：實際中的狀态應該比這個還要複雜，可能還會有“斷開”、“錯誤”……等等狀态），于是，我們可以把代碼寫成下面這樣，合并上面的嵌套條件，對于每一種組合都做出判斷。這樣一來，邏輯就會非常的幹淨和清楚。

<code></code><code>if</code> <code>(pA->isConnected() && ! pB->isConnected() ) {</code>

<code></code><code>pA->Write(</code><code>"Peer is not Ready, waiting"</code><code>);</code>

<code></code><code>}</code><code>else</code> <code>if</code> <code>( !pA->isConnected() && pB->isConnected() ) {</code>

<code></code><code>pB->Write(</code><code>"Peer is not Ready, waiting"</code><code>);</code>

<code></code><code>}</code><code>else</code> <code>if</code> <code>(pA->isConnected() && pB->isConnected() ) {</code>

<code></code><code>if</code> <code>( ! manager->ConnectTogther(pA, pB) ) {</code>

對于 <code>if-else</code> 語句來說，一般來說，就是檢查兩件事：錯誤和狀态。

對于檢查錯誤來說，使用 Guard Clauses 會是一種标準解，但我們還需要注意下面幾件事：

1）當然，出現錯誤的時候，還會出現需要釋放資源的情況。你可以使用 <code>goto fail;</code> 這樣的方式，但是最優雅的方式應該是C++面向對象式的 RAII 方式。

2）以錯誤碼傳回是一種比較簡單的方式，這種方式有很一些問題，比如，如果錯誤碼太多，判斷出錯的代碼會非常複雜，另外，正常的代碼和錯誤的代碼會混在一起，影響可讀性。是以，在更為高組的語言中，使用 <code>try-catch</code> 異常捕捉的方式，會讓代碼更為易讀一些。

對于檢查狀态來說，實際中一定有更為複雜的情況，比如下面幾種情況：

1）像TCP協定中的兩端的狀态變化。

2）像shell各個指令的指令選項的各種組合。

3）像遊戲中的狀态變化（一棵非常複雜的狀态樹）。

4）像文法分析那樣的狀态變化。

對于這些複雜的狀态變化，其本上來說，你需要先定義一個狀态機，或是一個子狀态的組合狀态的查詢表，或是一個狀态查詢分析樹。

寫代碼時，代碼的運作中的控制狀态或業務狀态是會讓你的代碼流程變得混亂的一個重要原因，重構“箭頭型”代碼的一個很重要的工作就是重新梳理和描述這些狀态的變遷關系。

好了，下面總結一下，把“箭頭型”代碼重構掉的幾個手段如下：

1）使用 Guard Clauses 。盡可能的讓出錯的先傳回，這樣後面就會得到幹淨的代碼。

2）把條件中的語句塊抽取成函數。有人說：“如果代碼不共享，就不要抽取成函數！”，持有這個觀點的人太死讀書了。函數是代碼的封裝或是抽象，并不一定用來作代碼共享使用，函數用于屏蔽細節，讓其它代碼耦合于接口而不是細節實作，這會讓我們的代碼更為簡單，簡單的東西都能讓人易讀也易維護，寫出讓人易讀易維護的代碼才是重構代碼的初衷！

4）對于多個狀态的判斷群組合，如果複雜了，可以使用“組合狀态表”，或是狀态機加Observer的狀态訂閱的設計模式。這樣的代碼即解了耦，也幹淨簡單，同樣有很強的擴充性。

5）重構“箭頭型”代碼其實是在幫你重新梳理所有的代碼和邏輯，這個過程非常值得為之付出。重新整思路去想盡一切辦法簡化代碼的過程本身就可以讓人成長。

作者：陳皓，部落格位址：https://coolshell.cn/articles/18190.html

如何重構“箭頭型”代碼

繼續閱讀

Oracle索引内部結構研究

MySQL和Lucene索引對比分析1. MySQL索引實作2. Lucene索引實作3. MySQL與Lucence對比參考：

一文搞定 MySQL 索引

MySQL（第五篇）—資料的完整性限制（2）（索引、引用完整性）資料的完整性限制（2）三、索引四、引用完整性

【MySQL索引】MySQL索引分類，90%的開發都不知道一、根據底層資料結構劃分二、根據索引字段個數劃分三、根據是否是在主鍵上建立的索引進行劃分四、根據資料與索引的存儲關聯性劃分五、其他分類六、總結

JS--------for循環删除數組元素

Python中字元串常見操作總結

Lucence的基本原理

sql執行計劃 explain 以及結合索引優化sql

MySQL - order by排序優化

2021-08-08 mysql索引

SQLServer 提升查詢速度

詳解SQL中幾種常用的表連接配接方式

oracle 中不使用已有的索引解決辦法

對first_name建立唯一索引uniq_idx_firstname問題描述Sql語句

記一次因MySQL編碼問題導緻的慢查詢排查