Golang為何舍棄三元運算符

三元運算符廣泛存在于其他語言中，比如：

python：

javascript：

c、c++：

然而，被廣泛支持的三目運算符在golang中卻是不存在的！如果我們寫出類似下面的代碼：

那么編譯器就該抱怨了：invalid character U+003F '?'。意思是golang中不存在?這個運算符，編譯器不認識而且非字母數字下劃線也不能用做變量名，自然也就當作是非法字符了。

然而這是為什么呢，其實官方給出了解釋，這里簡單引用一下：

The reason ?: is absent from Go is that the language's designers had seen the operation used too often to create impenetrably complex expressions. The if-else form, although longer, is unquestionably clearer. A language needs only one conditional control flow construct.

golang中不存在?:運算符的原因是因為語言設計者已經預見到三元運算符經常被用來構建一些極其復雜的表達式。雖然使用if進行替代會讓代碼顯得更長，但這毫無疑問可讀性更強。一個語言只需要有一種條件判斷結構就足夠了。

毫無疑問，這是在golang“大道至簡”的指導思想下的產物。

這段話其實沒問題，因為某些三元運算符的使用場景確實會降低代碼的可讀性：

乍一看確實很復雜，至少第二個表達式不花個20秒細看可能沒法理清控制流程（想象一下當縮進錯位或是完全沒有縮進的時候）。

如果把它們直接轉化成if語句是這樣的：

看起來并沒有多少的改善，特別是例2，三層嵌套，不管是誰review到這段代碼難免不會抱怨你幾句。

然而事實上這些代碼是可以簡化的，考慮到三元運算符總是會給變量一個值，因此最后的else其實可以看作是變量的默認值，于是代碼可以這么寫：

其次，對于例2，顯然可以使用else if來清除嵌套結構：

現在再來看，顯然使用if語句的版本的可讀性更高，邏輯也更清晰（通過去除嵌套）。

然而事實也不盡然。除了用三元運算符表達流程控制之外，事實上更常見更廣泛的一個應用是如下這樣的表達式：

類似上述通過一個簡短的條件表達式來確定變量的值，在開發中的出現頻率是相當高的。這時三元運算符的意圖更清晰，可讀性也較if語句更高，特別是配合匿名函數（lambda表達式）使用可以極大簡化我們的代碼。

對此python的解決之道是之支持上述的簡化版三元表達式，同時表達式不支持嵌套，達到了揚長避短的目的。不過代價是編譯器的相關實現會復雜化。

而對于golang來說一個簡單的能只通過單遍掃描即可完成ast構建的編譯器是其保持急速的構建速度的秘訣之一，為了這樣簡單的功能增加編譯器實現的復雜度是不可接受的。同時由于golang“大道至簡”的哲學，能用現有語法結構解決的問題，自然不會再添加新的語法。

不過還是有辦法的，雖然不推薦：

不推薦這么做是有幾個原因：

使用接口導致性能下降

需要強制的類型斷言

不管三元表達式還是if語句，對于不會到達的分支是不會計算的，也就是惰性計算;而給函數傳遞參數時每一個表達式都會被計算

最后總結一下：

三元運算符的優點：

對于簡短的表達式使用三元運算符表意更清晰，特別是在習慣了線性閱讀三元運算符表達式之后

不需要中間狀態（例如第一個例子中的let變量可以替換為const，代碼更健壯），心智負擔更低

沒有中間狀態也就意味著更少或完全沒有副作用，代碼更易跟蹤和維護

但三元運算符也有明顯的缺點：

對于復雜邏輯代碼可讀性較差（例如第一個例子中的status，需要在trueValue的位置進行進一步的條件判斷時）

容易被濫用，很多人將其用于替代if語句或是簡化復雜的if嵌套，這會導致上一條中所描述的結果

條件分支只能為表達式，不支持多條語句

所以這是一個見仁見智的問題，總之只能入鄉隨俗了。

審核編輯：黃飛