原文地址：13 Noteworthy Points from Google’s JavaScript Style Guide
原文作者：Daniel Simmons
譯者：命名最頭疼
對編碼風格不熟悉的人而言，Google 推出一套用於編寫 JavaScript 程式碼的樣式指南， 並指出（谷歌認為）編寫清晰易懂的程式碼最佳風格。
首先宣告一點，以下規則並不是編寫 Javascript 程式碼的硬性要求，僅是為了維持專案程式碼的一致性，Javascript 是一種靈活而寬鬆的語言，它允許各種風格。
Google 和 Airbnb 都推出了各自的編碼風格指南，且是比較受歡迎的，如果你的專案中需要編寫大量的JS程式碼，我絕對建議你閱讀。
以下列出了在 Google JS 風格指南中我認為比較有趣且實用的 13 條規則
Google對編碼中的每個細節點都進行了爭議(標籤, 空格,以及分號的使用)還有一些模糊的規範, 無疑, 這套風格肯定會改變我寫JS的方式。
對每一條規則，我都會列出規範的摘要部分，然後是樣式指南中的支援引用和詳細描述規則，在恰當的情況下，我將舉例說明，並與之和不遵循規則的程式碼進行對比。
推薦使用空格, 而不是tab鍵
除了行終止符以外，ASCII 中的水平空格字元 (0x20) 是唯一一個表示空格的空白字元，這意味著 Tab 鍵並不適用於縮排。
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
複製程式碼推薦使用分號, 而不是將其省略
每條語句結束後必須帶有分號，嚴禁依賴編譯器自動插入分號。 雖然我無法想象為什麼有人會反對這個想法，但是 JS 中一貫使用分號將成為新 "spaces versus tabs" 爭論，Google 表示堅持分號的使用。
// 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 模組
不要使用 ES6 模組（即 export 和 import 關鍵詞），因為它們的語義尚未最終確定，注意，一旦語義完全標準化，將重新審視這條規則。
// 現在先不要這樣用:
//------ 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';
複製程式碼不推薦水平對齊（但不禁止）
首先水平對齊這種做法是允許的，但是在 Google 風格中並不推薦這種用法。甚至不需要在已使用過的地方保持水平對齊。 水平對齊即在程式碼中新增空格，使每一列對齊。
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
複製程式碼不要再使用var
使用 const 或 let 宣告所有區域性變數，除非需要重新分配變數，否則預設使用 const，不推薦使用 var 關鍵詞。 我仍然看見人們在 StackOverflow 和其他地方使用 var 程式碼示例。可能有人會為此反對，或者說這是一種舊習慣，要改變，比較困難。
// bad
var example = 42;
// good
let example = 42;
複製程式碼首選箭頭函式 箭頭函式提供一個簡潔的句法，並解決了許多困難，首選箭頭函式而不是函式關鍵詞，尤其是巢狀函式 說句真心話，我認為箭頭函式非常棒，因為他們更加簡潔，更好看，事實證明，他們也有很重要的作用。
// 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;
});
複製程式碼使用模板字串代替連線符
在複雜字串上使用模板字串 （``） 而是不是連線符 （+） ，特別是涉及多個字串文字的情況下，模板字串可以跨行
// 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}?`;
}
複製程式碼對長字串不要使用行連續符
不要在普通字串或模板字串中使用行連續（即, 通過反斜槓結束字串文字內的一行）儘管 ES5 允許這樣做，如果有空格尾隨在後面，它將會導致棘手的錯誤，並且對讀者來說不那麼明顯。
有趣的是，Google 和 Airbnb 都不贊同這種做法這又Airbnb規範
谷歌的建議是通過連線符來拆分長字串（如下所示），而 Airbnb 則建議寫成一行，允許出現長字串（如果需要的話）
// bad (sorry, this doesn't show up well on mobile)
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是for迴圈首選
ES6 提供了三種不同的 for 迴圈。三個可用情況下，如果可以， 推薦優先使用 for-of 迴圈
包括我在內, 也覺得這條規則有點奇怪，但是谷歌認為它作為 for 迴圈的首選將會非常優雅
我認為，for...in 迴圈更適合物件，而 for...of 更適合陣列
雖然 Google 的規範並不一定能和我們想法相吻合, 但是它依舊覺得這種做法相當優雅
不要使用eval()
不要使用 eval 或 Function(...String) 建構函式（程式碼載入器除外），這些功能具有潛在風險，並且在 CSP 環境中無法正常工作。
對於 eval() 而言，在 MDN 頁面甚至專門有一頁去呼籲不要使用 eval()
// 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
複製程式碼常量應該用大寫字母和下劃線表示
常量名稱使用 CONSTANT_CASE: 全部為大寫字母，單詞用下劃線分割。
如果你能確保一個變數不會再改變，你可以通過大寫常量的名稱來表明這一點，這使得常量的不變性在整個程式碼的使用中顯而易見。
這個規則有個值得注意的例外是，如果常量是屬於函式範圍的，在這種情況下，應該將其用駝峰命名法來表示。
// bad
const number = 5;
// good
const NUMBER = 5;
複製程式碼每次只宣告一個變數
每個區域性宣告只宣告一個變數，例如 let a = 1, b = 2 是不被允許的。
// bad
let a = 1, b = 2, c = 3;
// good
let a = 1;
let b = 2;
let c = 3;
複製程式碼使用單引號而不是雙引號
普通的字元文字使用單引號（'）來分割，而不是雙引號（"）
Tip: 如果一個字串文字中包含單引號字元，請考慮使用模板字串，而避免使用轉義符號。
// 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 標準原始碼 ” 指南，你可以遵循這些規則，當然，很多人不同意，你可以部分遵循，甚至不遵循也可以。
我個人認為，很多情況下 Airbnb 比 Google 的規範更具吸引力，無論在何種情況下，一定要牢記，整個專案的編碼風格要保持統一。