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

阿里雲最近在作活動，低至2折，有興趣能夠看看：
https://promotion.aliyun.com/...

---

爲了保證的可讀性，本文采用意譯而非直譯。

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等着你！

對於那些還不熟悉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

你的點贊是我持續分享好東西的動力，歡迎點贊！

交流

乾貨系列文章彙總以下，以爲不錯點個Star，歡迎 加羣 互相學習。

https://github.com/qq44924588...

我是小智，公衆號「大遷世界」做者，對前端技術保持學習愛好者。我會常常分享本身所學所看的乾貨，在進階的路上，共勉！

關注公衆號，後臺回覆福利，便可看到福利，你懂的。