esnext 最後乙個引數後面也允許加逗號了

目前是乙個 stage 3 的提案，chakra 和 jsc 已經實現了，它允許我們在函式定義時的最後乙個形參和函式呼叫時的最後乙個實參的尾部加上逗號。

注意：最後乙個引數加逗號的優點只在引數分行寫時才能體現出來。

優點1：修改**時不容易出錯

假如當前的**長這樣：

function
foo(
param1,
param2,
param3
)

而你此時要做的是刪除 param3 引數的實現，這時你很有可能把游標定位到 param3 那一行，連續按下 command+x 和 command+s 了事（sublime）:

function
foo(
param1,
param2,
)

一測試，syntaxerror！恍然大悟，回去再把逗號刪掉。

假如是新增乙個引數呢，問題也類似，你得留心給上乙個引數補上逗號；調整引數的順序（sublime 用 ctrl + command + ↑↓）也類似。除了形參，函式呼叫時傳入的實參也乙個道理。

如果每個引數尾部都已經加上了逗號，那麼就不存在上面說的這些問題了。

優點2：對 git/hg blame 更友好

我專門用 git 生成了乙個演示用的倉庫，裡面有乙個演示檔案 test.js：

我現在想知道 param3 和對應的 arg3 是誰在哪個 commit 裡加上去，所以我會執行 git blame test.js：

git blame 告訴我，是小李在 11e537fc 這次 commit 裡加的。但當你檢視那個 commit 的變更時，就會發現，錯了，小李只是在實現 param4 時迫於無奈給 param3 補了個逗號，完整的 git log -p test.js 才能看到真相，真正實現 param3 的是小張，而且同時也能發現，小張在實現 param3 的時候也被迫改動了 param2 那一行：

如果每一行引數尾部都有逗號，那麼開發人員就不需要修改和本次 commit 無關的行，從而就不會汙染 git/hg blame。

有些同學就問了：「這提案對我沒用啊，我所有的引數都是寫在一行裡的」。的確，如果你從不把引數分行寫，那你壓根用不上這個特性。不過，引數分行寫的確是有用的：

優點1：能避免行過長

如果引數太多，或者某個實參是個長字串，那麼引數寫在一行就會讓編輯器出現橫向滾動條，既不美觀，也不好讀。

優點2：對 git/hg blame 更友好

就像前面演示的，如果你所有的引數都寫在一行裡，你就無法 blame 到每個引數被新增的 commit。有些同學懷疑了？真的有人這麼寫嗎？是真的，我電腦上剛好有個 v8 的倉庫，我們用下面的 grep 命令查詢一下：

grep -zopr --include='
*.js''
function \w+\(\n([\s\w]+,(.+)?\n)+[\s\w]+\)
'

果然找到了乙個：

git blame 一下呢：

每個引數的 commit 都能方便的拿到！這在多人合作的開源專案裡很重要。

優點3：避免分支衝突

顯而易見，兩個分支同時在一行上新增新的引數，必然會產生衝突。

優點4：方便加注釋

如果你需要為每個引數新增注釋，除了分行寫還有什麼選擇嗎？同樣在 v8 的倉庫裡 grep 到了真實案例，是給每個實參加了注釋：

對，上面說的加逗號的優點和分行的優點對 {} 和同樣適用，{} 是在 es5 裡支援尾部加逗號的，從誕生時就支援，因為它需要支援稀疏陣列，比如 [1,,,]。

「什麼時候 json 規範能改，不統一掉很難受啊？」是啊，我也想，但我也不知道什麼時候能改。

es8（2017）還是 es9（2018）？不要再 care 了，現在是先有實現後進規範，就像 chrome 的版本號一樣，隨它漲去吧。目前 spidermonkey 和 v8 還沒開始實現，我已經給 v8 提了需求

下面這些都是 syntaxerror：

function foo(,){} //
沒引數只有個逗號
function foo(param1,,){} //
連續的兩個逗號
function foo(param1,...rest,){} //
剩餘引數後面還有逗號，因為剩餘引數必須是最後乙個引數

esnext 最後乙個引數後面也允許加逗號了

最後乙個錯誤

sql擷取取最後乙個符號後面的內容（或前面）

VLOOKUP函式最後乙個引數導致的問題

esnext 最後乙個引數後面也允許加逗號了

最後乙個錯誤

sql擷取取最後乙個符號後面的內容（或前面）

VLOOKUP函式最後乙個引數導致的問題

相關推薦