谷歌的JavaScript編寫風格中 13點值得我們注意的！

　　對於那些還不熟悉JavaScript的編寫風格的人，谷歌提供了編寫JavaScript的編寫風格指南，谷歌風格指南 其中列出了編寫乾淨、可理解程式碼的最佳風格實踐。

　　對於編寫有效的JavaScript來說，這些並不是硬性的、快速的規則，而只是在原始檔中維護一致的、吸引人的樣式選擇的規則。這對於JavaScript來說尤其有趣，它是一種靈活且多變的語言，允許多種風格的選擇。

　　谷歌和Airbnb有兩個最受歡迎的編寫風格指南。如果我的工作是花費大量時間編寫JS，那麼可以先學習這兩種方法。

　　以下是谷歌JS風格指南中我認為最有趣和相關的13條規則：

　　谷歌JS風格指南處理各種各樣的問題，從激烈爭論的問題(製表符與空格的比較，以及分號應該如何使用這個有爭議的問題)，到一些更模糊的規範，這些規範令我吃驚，它們肯定會改變我以後寫JS的方式。

　　對於每個規則，我將對規範進行總結，然後引用樣式指南中的支援部分，詳細描述該規則。在適用的情況下，我還將提供實踐中的樣式示例，並將其與不遵循規則的程式碼進行對比。

　　使用空格，而不是製表符

除了行結束符序列之外，ASCII水平空格字元(0x20)是原始檔中出現在任何位置的惟一空格字元。這意味著…製表符不用於縮排

　　使用兩個空格(而不是四個)進行縮排

// bad
function foo() {
∙∙∙∙let name;
}

// bad
function bar() {
∙let name;
}

// good
function baz() {
∙∙let name;
}

　　分號是必需的

每個語句必須以分號結束，禁止依靠自動分號插入。

　　雖然無法想象為什麼會有人反對這個想法，但JS中分號的一致使用正在成為新的“空格對製表符”的爭論。谷歌一慣建議結束需要使用分號。

// 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模組(即匯出和匯入關鍵字)，因為它們的語義還沒有最終確定。注意，一旦語義完全標準，將重新定義使用的方式。

// 先別做這種事
//------ 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';

　　不鼓勵(但不禁止)水平對齊

這種做法是允許的，但谷歌編寫風格通常不鼓勵這樣做，甚至不需要在已經使用它的地方保持水平對齊。

　　水平對齊是在程式碼中新增可變數量的額外空格，以使某行變數的值與前面變數值對齊。

// bad
{
  tiny:   42,  
  longer: 435, 
};

// good
{
  tiny: 42, 
  longer: 435,
};

　　不要再使用var了

使用const或let宣告所有本地變數來代替 var。預設情況下使用 const，除非需要重新分配變數在使用 let 宣告。

// bad
var example = 42;

// good
let example = 42;

　　箭頭函式是首選

箭頭函式提供了簡潔的語法，並解決了this 在函式中不確定性的一些問題，與function關鍵字相比，更喜歡箭頭函式，特別是對於巢狀函式。

　　老實說，我只是覺得箭頭函式很棒因為它們更簡潔，更美觀。事實證明，它們還有一個非常重要的用途。

// 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允許這樣做，但是如果斜槓後面有任何尾隨空格，那麼可能會導致一些棘手的錯誤，而且對讀者來說不太明顯。

　　有趣的是，谷歌和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環境中根本不起作用

　　MDN 頁面的eval()中，甚至有一個名為“不要使用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的格式:所有大寫字母，單詞由下劃線分隔。

　　如果您絕對確信某個變數不應該更改，那麼可以通過將該常量的名稱大寫來表示。這使得在整個程式碼中使用該常量時，它的不變性非常明顯。

　　一個值得注意的例外是，如果常量是函式作用域的。在這種情況下，應該用camelCase來寫。

// bad
const number = 5;

// good
const NUMBER = 5;

　　每次宣告一個變數

　　每個區域性變數宣告只宣告一個變數:宣告如令a = 1, b = 2，不推薦。

// bad
let a = 1, b = 2, c = 3;

// good
let a = 1;
let b = 2;
let c = 3;

　　使用單引號，而不是雙引號

普通的字串用單引號(')分隔，而不是雙引號(")。
提示:如果字串包含單引號字元，可以考慮使用模板字串來避免轉義引號。

// 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`;

　　最後一個注意

　　正如我在開始時所說，這些不是強制要求。谷歌只是眾多科技巨頭之一，這些只是推薦。

　　也就是說，看看谷歌這樣的公司提出的風格建議是很有趣的，這家公司僱傭了很多才華橫溢的人，他們花了很多時間編寫優秀的程式碼。

　　如果你想要遵循“符合谷歌的原始碼”的指導原則，那麼你可以遵循這些規則—但是，當然，許多人不同意這些規則，你可以隨意忽略這些規則中的任何一個或所有規則。

　　我個人認為在很多情況下Airbnb的規範比谷歌更有吸引力。無論您對這些特定的規則採取何種立場，在編寫任何型別的程式碼時，始終牢記風格一致性仍然很重要。

　　原文：13 Noteworthy Points from Google’s JavaScript Style Guide