摘要：谷歌和有兩個(gè)最受歡迎的編寫(xiě)風(fēng)格指南。有趣的是，谷歌和不同意這個(gè)規(guī)則這是的規(guī)范。谷歌只是眾多科技巨頭之一，這些只是推薦。也就是說(shuō)，看看谷歌這樣的公司提出的風(fēng)格建議是很有趣的，這家公司雇傭了很多才華橫溢的人，他們花了很多時(shí)間編寫(xiě)優(yōu)秀的代碼。

文中的我指原文的作者

想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年百來(lái)篇優(yōu)質(zhì)文章等著你！

對(duì)于那些還不熟悉JavaScript的編寫(xiě)風(fēng)格的人，谷歌提供了編寫(xiě)JavaScript的編寫(xiě)風(fēng)格指南，谷歌風(fēng)格指南 其中列出了編寫(xiě)干凈、可理解代碼的最佳風(fēng)格實(shí)踐。

對(duì)于編寫(xiě)有效的JavaScript來(lái)說(shuō)，這些并不是硬性的、快速的規(guī)則，而只是在源文件中維護(hù)一致的、吸引人的樣式選擇的規(guī)則。這對(duì)于JavaScript來(lái)說(shuō)尤其有趣，它是一種靈活且多變的語(yǔ)言，允許多種風(fēng)格的選擇。

谷歌和Airbnb有兩個(gè)最受歡迎的編寫(xiě)風(fēng)格指南。如果我的工作是花費(fèi)大量時(shí)間編寫(xiě)JS，那么可以先學(xué)習(xí)這兩種方法。

以下是谷歌JS風(fēng)格指南中我認(rèn)為最有趣和相關(guān)的13條規(guī)則：

谷歌JS風(fēng)格指南處理各種各樣的問(wèn)題，從激烈爭(zhēng)論的問(wèn)題(制表符與空格的比較，以及分號(hào)應(yīng)該如何使用這個(gè)有爭(zhēng)議的問(wèn)題)，到一些更模糊的規(guī)范，這些規(guī)范令我吃驚，它們肯定會(huì)改變我以后寫(xiě)JS的方式。

對(duì)于每個(gè)規(guī)則，我將對(duì)規(guī)范進(jìn)行總結(jié)，然后引用樣式指南中的支持部分，詳細(xì)描述該規(guī)則。在適用的情況下，我還將提供實(shí)踐中的樣式示例，并將其與不遵循規(guī)則的代碼進(jìn)行對(duì)比。

除了行結(jié)束符序列之外，ASCII水平空格字符(0x20)是源文件中出現(xiàn)在任何位置的惟一空格字符。這意味著…制表符不用于縮進(jìn)

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

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

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

每個(gè)語(yǔ)句必須以分號(hào)結(jié)束，禁止依靠自動(dòng)分號(hào)插入。

雖然無(wú)法想象為什么會(huì)有人反對(duì)這個(gè)想法，但JS中分號(hào)的一致使用正在成為新的“空格對(duì)制表符”的爭(zhēng)論。谷歌一慣建議結(jié)束需要使用分號(hào)。

// 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模塊(即導(dǎo)出和導(dǎo)入關(guān)鍵字)，因?yàn)樗鼈兊恼Z(yǔ)義還沒(méi)有最終確定。注意，一旦語(yǔ)義完全標(biāo)準(zhǔn)，將重新定義使用的方式。

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

這種做法是允許的，但谷歌編寫(xiě)風(fēng)格通常不鼓勵(lì)這樣做，甚至不需要在已經(jīng)使用它的地方保持水平對(duì)齊。

水平對(duì)齊是在代碼中添加可變數(shù)量的額外空格，以使某行變量的值與前面變量值對(duì)齊。

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

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

使用const或let聲明所有本地變量來(lái)代替 var。默認(rèn)情況下使用 const，除非需要重新分配變量在使用 let 聲明。

// bad
var example = 42;

// good
let example = 42;

箭頭函數(shù)提供了簡(jiǎn)潔的語(yǔ)法，并解決了this 在函數(shù)中不確定性的一些問(wèn)題，與function關(guān)鍵字相比，更喜歡箭頭函數(shù)，特別是對(duì)于嵌套函數(shù)。

老實(shí)說(shuō)，我只是覺(jué)得箭頭函數(shù)很棒因?yàn)樗鼈兏?jiǎn)潔，更美觀。事實(shí)證明，它們還有一個(gè)非常重要的用途。

// 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;
});

在復(fù)雜的字符串連接上使用模板字符串(用`分隔)，特別是在涉及多個(gè)字符串文本時(shí)，模板字符串可以跨越多行。

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

不要在普通或模板字符串文字中使用連續(xù)行(也就是說(shuō)，在字符串文字中以反斜杠結(jié)束一行)。盡管ES5允許這樣做，但是如果斜杠后面有任何尾隨空格，那么可能會(huì)導(dǎo)致一些棘手的錯(cuò)誤，而且對(duì)讀者來(lái)說(shuō)不太明顯。

有趣的是，谷歌和Airbnb不同意這個(gè)規(guī)則(這是Airbnb的規(guī)范)。

雖然谷歌建議連接更長(zhǎng)的字符串(如下所示)，Airbnb的風(fēng)格指南基本上建議什么也不做，并允許長(zhǎng)字符串繼續(xù)，只要他們需要。

// 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.";

使用ES6，該語(yǔ)言現(xiàn)在有三種不同的for循環(huán)。所有的循環(huán)都可以使用，但是如果可能的話(huà)，for-of循環(huán)應(yīng)該是首選的。

如果您問(wèn)我，這是一個(gè)奇怪的問(wèn)題，但是我認(rèn)為我應(yīng)該包含它，因?yàn)楣雀杪暶髁艘环N首選的for循環(huán)類(lèi)型，這非常有趣。

我總覺(jué)得 for...in 循環(huán)對(duì)于對(duì)象更好，而對(duì)于for...of 的更適合數(shù)組，不同場(chǎng)景可以使用不同方式。

雖然這里的Google規(guī)范不一定與這個(gè)想法相矛盾，但是了解他們特別喜歡這個(gè)循環(huán)還是很有趣的。

不要使用eval或function(…string)構(gòu)造函數(shù)(代碼加載器除外)。這些特性具有潛在的危險(xiǎn)，而且在CSP環(huán)境中根本不起作用

MDN 頁(yè)面的eval()中，甚至有一個(gè)名為“不要使用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

常量名稱(chēng)使用CONSTANT_CASE的格式:所有大寫(xiě)字母，單詞由下劃線分隔。

如果您絕對(duì)確信某個(gè)變量不應(yīng)該更改，那么可以通過(guò)將該常量的名稱(chēng)大寫(xiě)來(lái)表示。這使得在整個(gè)代碼中使用該常量時(shí)，它的不變性非常明顯。

一個(gè)值得注意的例外是，如果常量是函數(shù)作用域的。在這種情況下，應(yīng)該用camelCase來(lái)寫(xiě)。

// bad
const number = 5;

// good
const NUMBER = 5;

每個(gè)局部變量聲明只聲明一個(gè)變量:聲明如令a = 1, b = 2，不推薦。

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

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

普通的字符串用單引號(hào)(")分隔，而不是雙引號(hào)(")。 
提示:如果字符串包含單引號(hào)字符，可以考慮使用模板字符串來(lái)避免轉(zhuǎn)義引號(hào)。

// bad
let directive = "No identification of self or mission."
// bad
let saying = "Say it ainu0027t so.";

// good
let directive = "No identification of self or mission.";
// good
let saying = `Say it ain"t so`;

正如我在開(kāi)始時(shí)所說(shuō)，這些不是強(qiáng)制要求。谷歌只是眾多科技巨頭之一，這些只是推薦。

也就是說(shuō)，看看谷歌這樣的公司提出的風(fēng)格建議是很有趣的，這家公司雇傭了很多才華橫溢的人，他們花了很多時(shí)間編寫(xiě)優(yōu)秀的代碼。

如果你想要遵循“符合谷歌的源代碼”的指導(dǎo)原則，那么你可以遵循這些規(guī)則—但是，當(dāng)然，許多人不同意這些規(guī)則，你可以隨意忽略這些規(guī)則中的任何一個(gè)或所有規(guī)則。

我個(gè)人認(rèn)為在很多情況下Airbnb的規(guī)范比谷歌更有吸引力。無(wú)論您對(duì)這些特定的規(guī)則采取何種立場(chǎng)，在編寫(xiě)任何類(lèi)型的代碼時(shí)，始終牢記風(fēng)格一致性仍然很重要。

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

你的點(diǎn)贊是我持續(xù)分享好東西的動(dòng)力，歡迎點(diǎn)贊！

干貨系列文章匯總?cè)缦?，覺(jué)得不錯(cuò)點(diǎn)個(gè)Star，歡迎 加群 互相學(xué)習(xí)。

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

我是小智，公眾號(hào)「大遷世界」作者，對(duì)前端技術(shù)保持學(xué)習(xí)愛(ài)好者。我會(huì)經(jīng)常分享自己所學(xué)所看的干貨，在進(jìn)階的路上，共勉！

關(guān)注公眾號(hào)，后臺(tái)回復(fù)福利，即可看到福利，你懂的。