最近在 Code Review 代碼倉庫的一些提交代碼，發現了一些代碼問題，同時也多了一些想法，接下來分享給大家。

多用可選鏈

很多在判斷對象中的屬性，會有意識地去使用 && 判空，這是好習慣，但是其實如果用 ?. 可選鏈的話，代碼會更加的簡潔。

圖片

當你不確定函數是否存在的時候，也可以使用可選鏈。

圖片

多用includes

當一個變量需要進行多值判斷的時候，很多人會這么去寫。

圖片

但是這么寫，如果條件非常多的時候，寫起來會非常不優雅，并且不好維護，想象一下，如果變量 a 改名了，那么，所有三等式子都得改變量名，所以這里其實可以使用 includes 來進行優化。

圖片

函數參數盡量使用對象

很多人在寫一個函數并定義參數的時候會這么去做，這么寫很容易有一個問題，那就是中間有一些參數是可選的時候，就比如中間 b 其實我不想傳的，但由于你這么定義參數傳入方式，導致我需要傳一個 undefined 進行占位。

圖片

所以我建議是函數參數盡量使用對象，這樣的話好拓展，并且傳參方式更加靈活，像 b 其實我根本就不用使用占位去傳了。

圖片

魔法變量寫注釋 & 常量命名

魔法變量 是什么呢？我理解就是一些寫死在代碼里的值，比如以下：

圖片

像這樣寫死在代碼里的值，其實可維護性很差，因為接手的人根本不知道這些值是什么意思，所以這種魔法變量最好是能寫好注釋。

圖片

或者你如果不想注釋，你可以用一個常量保存起來，并且這些常量的命名必須清晰。

圖片

盡量減少副作用

很多人在寫函數的時候，會經常寫一些 副作用，什么是 副作用 呢？其實就是原本不屬于這個函數該干的事，比如下面代碼：

圖片

上面這個計算函數其實已經 不純 了，因為他有了副作用，所以寫函數應該職責單一，這樣可復用性更高

圖片

使用 else if

很多人在進行多 if 判斷時，喜歡只使用 if 去判斷，但其實他們不知道這樣是有隱患的。

圖片

有什么隱患呢？請看下面代碼，下面代碼會導致兩個 if 都為真。

圖片

所以有時候得多使用 else if ，就不會有這些隱患啦！

圖片

策略模式

請看下面這段代碼，這樣寫的缺點在于，變量名一改，全部地方都得改，并且后面想要加額外的判斷條件也比較麻煩。

圖片

所以可以使用策略模式。

圖片

當有多判斷進行方法執行的時候，也可以使用策略模式。

圖片

圖片

記得兜底

雖然現在有 TypeScript 的類型提示，但是它并沒有運行時校驗，所以一些場景中一定要記得判斷兜底。

圖片

在進行一些復雜的解析工作的時候，要使用 try...catch 來兜底。

圖片