Google為了那些還不熟悉代碼規範的人發布了壹個JS代碼規範。其中列出了編寫簡潔易懂的代碼所應該做的最佳實踐。
代碼規範並不是壹種編寫正確JavaScript代碼的規則，而是為了保持源代碼編寫模式壹致的壹種選擇。對於JavaScript語言尤其如此，因為它靈活並且約束較少，允許開發者使用許多不同的編碼樣式。
Google和Airbnb各自占據著當前最流行的編碼規範的半壁江山。如果妳會在編寫JS代碼上投入很長時間的話，我強烈推薦妳通讀壹遍這兩家公司的編碼規範。
接下來要寫的是我個人認為在Google的代碼規範中，與日常開發密切相關的十三條規則。
它們處理的問題都非常具有爭議性，包括tab與空格、是否強制使用分號等等。還有壹些令我感到驚訝的規則，往往最後都改變了我編寫JS代碼的習慣。
對於每壹條規則，我都會先給出規範的摘要，然後引用規範中的詳細說明。我還會舉壹些適當的反例論證遵守這些規則的重要性。
使用空格代替tab除了每壹行的終止符序列，ASCII水平空格符（0x20）是唯壹壹個可以出現在源文件中任意位置的空格字符。這也意味著，tab字符不應該被使用，以及被用來控制縮進。
規範隨後指出應該使用2個，而不是4個空格帶實現縮進。
// bad
function foo() {
let name;
}
// bad
function bar() {
let name;}
// good
function baz() {
let name;}不能省略分號每個語句必須以分號結尾。不允許依賴於JS自動添加分號的功能。
盡管我不明白為什麽會有人反對這個規則，但目前分號的使用問題顯然已經像“空格 vs tab”這個問題壹樣產生了巨大的爭議。而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 module由於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';譯者註：感覺遵守這條規範不大現實，畢竟現在已經有babel了。而且使用React時，最佳實踐就是使用ES6模塊吧。
不推薦代碼水平對齊Google的代碼規範允許但不推薦對代碼進行水平對齊。即使之前的代碼中做了水平對齊的處理，以後也應該避免這種行為。
對代碼進行水平對齊會在代碼中添加若幹多余的空格，這讓相鄰兩行的字符看上去處於壹條垂直線上。
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};杜絕var使用const或let來聲明所有局部變量。如果變量不需要被重新賦值，默認應該使用const。應該拒絕使用關鍵字var。
我不知道是因為沒有人能說服他們，還是說因為舊習難改。目前我仍能看到許多人在StackOverFlow或其他地方使用var聲明變量。
// bad
var example = 42;
// good
const 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}?`;
}不要使用續行符分割長字符串在JS中，\也代表著續行符。Google的代碼規範不允許在不管是模板字符串還是普通字符串中使用續行符。盡管ES5中允許這麽做，但如果在\後跟著某些結束空白符，這種行為會導致壹些錯誤，而這些錯誤在審閱代碼時很難註意到。
這條規則很有趣，因為Airbnb的規範中有壹條與之不相同的規則
Google推薦下面這樣的寫法，而Airbnb則認為應該順其自然，不做特殊處理，該多長就多長。
// 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語句。
// 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常量的命名規範常量命名應該使用全大寫格式，並用下劃線分割
如果妳確定壹定以及肯定壹個變量值以後不會被修改，妳可以將它的名稱使用全大寫模式改寫，暗示這是壹個常量，請不要修改它的值。
遵守這條規則時需要註意的壹點是，如果這個常量是壹個函數，那麽應該使用駝峰式命名法。
// 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;使用單引號只允許使用單引號包裹普通字符串，禁止使用雙引號。如果字符串中包含單引號字符，應該使用模板字符串。
// 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的代碼規範要出色。但不管妳支持哪壹種，也不管妳編寫的是什麽類型的代碼，最重要的是在腦海中時刻遵守著同壹份代碼規範。
相信看了本文案例妳已經掌握了方法，更多精彩請關註Gxl網其它相關文章！
推薦閱讀：
express默認日誌組件morgan的詳細介紹
Vue基於Nuxt.js實現服務端渲染的具體步奏