Google為了那些還不熟悉程式碼規範的人釋出了一個JS程式碼規範。其中列出了編寫簡潔易懂的程式碼所應該做的最佳實踐。
程式碼規範並不是一種編寫正確JavaScript程式碼的規則，而是為了保持原始碼編寫模式一致的一種選擇。對於JavaScript語言尤其如此，因為它靈活並且約束較少，允許開發者使用許多不同的編碼樣式。
Google和Airbnb各自佔據著當前最流行的編碼規範的半壁江山。如果你會在編寫JS程式碼上投入很長時間的話，我強烈推薦你通讀一遍這兩家公司的編碼規範。
接下來要寫的是我個人認為在Google的程式碼規範中，與日常開發密切相關的十三條規則。
它們處理的問題都非常具有爭議性，包括tab與空格、是否強制使用分號等等。還有一些令我感到驚訝的規則，往往最後都改變了我編寫JS程式碼的習慣。
對於每一條規則，我都會先給出規範的摘要，然後引用規範中的詳細說明。我還會舉一些適當的反例論證遵守這些規則的重要性。
使用空格代替tab
除了每一行的終止符序列，ASCII水平空格符（0x20）是唯一一個可以出現在原始檔中任意位置的空格字元。這也意味著，tab字元不應該被使用，以及被用來控制縮排。
規範隨後指出應該使用2個，而不是4個空格帶實現縮排。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// bad function foo() { ∙∙∙∙let name; } // bad function bar() { ∙let name; } // good function baz() { ∙∙let name; } |
不能省略分號
每個語句必須以分號結尾。不允許依賴於JS自動新增分號的功能。
儘管我不明白為什麼會有人反對這個規則，但目前分號的使用問題顯然已經像“空格 vs tab”這個問題一樣產生了巨大的爭議。而Google對此表示分號是必須的，是不可省略的。
|
1 2 3 4 5 6 7 8 9 10 |
// bad let luke = {} let leia = {} [luke, leia].forEach(jedi => jedi.father = 'vader') // good let luke = {}; let leia = {}; [luke, leia].forEach((jedi) => { jedi.father = 'vader'; }); |
暫時不要使用ES6 module
由於ES6模組的語義尚不完全確定，所以暫時不要使用，比如export和import關鍵字。一旦它們的相關規範制定完成，那麼請忽略這一條規則。
|
1 2 3 4 5 6 7 8 9 10 11 |
// 暫時不要編寫下面的程式碼： //------ lib.js ------ export function square(x) { return x * x; } export function diag(x, y) { return sqrt(square(x) + square(y)); } //------ main.js ------ import { square, diag } from 'lib'; |
譯者注：感覺遵守這條規範不大現實，畢竟現在已經有babel了。而且使用React時，最佳實踐就是使用ES6模組吧。
不推薦程式碼水平對齊
Google的程式碼規範允許但不推薦對程式碼進行水平對齊。即使之前的程式碼中做了水平對齊的處理，以後也應該避免這種行為。
對程式碼進行水平對齊會在程式碼中新增若干多餘的空格，這讓相鄰兩行的字元看上去處於一條垂直線上。
|
1 2 3 4 5 6 7 8 9 10 |
// bad { tiny: 42, longer: 435, }; // good { tiny: 42, longer: 435, }; |
杜絕var
使用const或let來宣告所有區域性變數。如果變數不需要被重新賦值，預設應該使用const。應該拒絕使用關鍵字var。
我不知道是因為沒有人能說服他們，還是說因為舊習難改。目前我仍能看到許多人在StackOverFlow或其他地方使用var宣告變數。
|
1 2 3 4 |
// bad var example = 42; // good const example = 42; |
優先使用箭頭函式
箭頭函式提供了一種簡潔的語法，並且避免了一些關於this指向的問題。相比較與function關鍵字，開發者應該優先使用箭頭函式來宣告函式，尤其是宣告巢狀函式。
坦白說，我曾以為箭頭函式的作用只在於簡潔美觀。但現在我發現原來它們還有更重要的作用。
|
1 2 3 4 5 6 7 8 9 10 11 |
// bad [1, 2, 3].map(function (x) { const y = x + 1; return x * y; }); // good [1, 2, 3].map((x) => { const y = x + 1; return x * y; }); |
使用模板字串取代連線字串
在處理多行字串時，模板字串比複雜的拼接字串要表現的更出色。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// bad function sayHi(name) { return 'How are you, ' + name + '?'; } // bad function sayHi(name) { return ['How are you, ', name, '?'].join(); } // bad function sayHi(name) { return `How are you, ${ name }?`; } // good function sayHi(name) { return `How are you, ${name}?`; } |
不要使用續行符分割長字串
在JS中，
\也代表著續行符。Google的程式碼規範不允許在不管是模板字串還是普通字串中使用續行符。儘管ES5中允許這麼做，但如果在\後跟著某些結束空白符，這種行為會導致一些錯誤，而這些錯誤在審閱程式碼時很難注意到。
這條規則很有趣，因為Airbnb的規範中有一條與之不相同的規則
Google推薦下面這樣的寫法，而Airbnb則認為應該順其自然，不做特殊處理，該多長就多長。
|
1 2 3 4 5 6 7 8 9 10 |
// bad (建議在PC端閱讀) const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.'; // good const longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.'; |
優先使用for...of
在ES6中，有3種不同的for迴圈。儘管每一種有它的應用場景，但Google仍推薦使用
for...of。
真有趣，Google居然會特別指定一種for迴圈。雖然這很奇怪，但不影響我接受這一觀點。
以前我認為for...in適合遍歷Object，而for...of適合遍歷陣列。因為我喜歡這種各司其職的使用方式。
儘管Google的規範與這種使用方式相沖突，但Google對for...of的偏愛依然讓我覺得十分有趣。
不要使用eval語句
除非是在code loader中，否則不用使用eval或是Function(…string)結構。這個功能具有潛在的危險性，並且在CSP環境中無法起作用。
MDN中有一節專門提到不要使用eval語句。
|
1 2 3 4 5 6 7 8 |
// bad let obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" eval( 'var result = obj.' + propName ); // good let obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a |
常量的命名規範
常量命名應該使用全大寫格式，並用下劃線分割
如果你確定一定以及肯定一個變數值以後不會被修改，你可以將它的名稱使用全大寫模式改寫，暗示這是一個常量，請不要修改它的值。
遵守這條規則時需要注意的一點是，如果這個常量是一個函式，那麼應該使用駝峰式命名法。
|
1 2 3 4 |
// bad const number = 5; // good const NUMBER = 5; |
每次只宣告一個變數
每一個變數宣告都應該只對應著一個變數。不應該出現像
let a = 1,b = 2;這樣的語句。
|
1 2 3 4 5 6 |
// bad let a = 1, b = 2, c = 3; // good let a = 1; let b = 2; let c = 3; |
使用單引號
只允許使用單引號包裹普通字串，禁止使用雙引號。如果字串中包含單引號字元，應該使用模板字串。
|
1 2 3 4 5 6 7 8 |
// bad let directive = "No identification of self or mission." // bad let saying = 'Say it ain\u0027t so.'; // good let directive = 'No identification of self or mission.'; // good let saying = `Say it ain't so`; |
總結
就像我在開頭所說那樣，規範中沒有需要強制執行的命令。儘管Google是科技巨頭之一，但這份程式碼規範也僅僅是用來當作參考罷了。
Google是一家人才匯聚的科技公司，僱傭著出色的程式設計師來編寫優秀的程式碼。能夠看到這樣的公司釋出的程式碼規範是一件很有趣的事情。
如果你想要實現一種Google式的程式碼，那麼你可以在專案中制定這些規範。但你可能並不贊成這份程式碼規範，這時也沒有人會阻攔你捨棄其中某些規則。
我個人認為在某些場景下，Airbnb的程式碼規範比Google的程式碼規範要出色。但不管你支援哪一種，也不管你編寫的是什麼型別的程式碼，最重要的是在腦海中時刻遵守著同一份程式碼規範。
檢視更多我翻譯的Medium文章請訪問：
專案地址：https://github.com/WhiteYin/translation
SF專欄：https://segmentfault.com/blog/yin-translation