Google為不熟悉的人發布了JS代碼規範。它列出了編寫簡明易懂的代碼的最佳實踐。
代碼規範不是編寫正確JavaScript代碼的規則，而是保持源代碼編寫模式壹致的選擇。對於JavaScript語言來說尤其如此，因為它靈活且較少受限，允許開發人員使用許多不同的編碼風格。
Google和Airbnb各自占據了最流行的編碼規範的半壁江山。如果妳會花很長時間寫JS代碼，我強烈建議妳通讀這兩家公司的編碼規範。
接下來，我將在Google的代碼規範中，寫出我個人認為與日常開發密切相關的十三條規則。
他們處理的問題爭議很大，包括制表符和空格，分號是否強制等等。還有壹些規則讓我很驚訝，往往到最後會改變我寫JS代碼的習慣。
對於每壹條規則，我都會先給出規範的概要，然後引用規範中的詳細說明。我還會舉壹些適當的反例來說明遵守這些規則的重要性。
使用空格代替制表符。除了每行的終止符序列，ASCII水平空格字符(0x20)是唯壹可以出現在源文件中任何地方的空格字符。這也意味著不應該使用制表符來控制縮進。
規範然後指出縮進應該用2個空格而不是4個空格來實現。
//壞
函數foo() {
讓名字；
}
//壞
功能欄(){
讓名字；
}
//很好
函數baz() {
讓名字；
}不能省略分號。每個語句都必須以分號結束。不允許依賴JS自動添加分號。
雖然我不明白為什麽會有人反對這個規則，但是分號的使用顯然和“空格vs制表符”的問題壹樣有爭議。Google的分號是必須的，不能省略。
//壞
讓盧克= {}
讓萊婭= {}
[盧克，萊婭]。forEach(Jedi = & gt；絕地。父親= '維德')
//很好
讓盧克= { }；
讓萊婭= { }；
[盧克，萊婭]。forEach((Jedi)= & gt；{
jedi.father = ' vader
});暫時不用ES6模塊。因為ES6模塊的語義還沒有完全確定，所以暫時不用，比如導出和導入關鍵字。壹旦制定了相關規範，請忽略此規則。
//暫時不要寫下面的代碼:
// - lib.js -
導出功能方塊(x) {
返回x * x
}
導出函數diag(x，y) {
返回sqrt(square(x)+square(y))；
}
// - main.js -
從“lib”導入{ square，diag }；譯者註:我感覺遵守這個規範是不現實的。畢竟現在有巴別塔。而在使用React時，最好的做法是使用ES6模塊。
不建議代碼水平對齊。Google的代碼規範允許但不建議代碼水平對齊。即使水平對齊是在前面的代碼中完成的，將來也應該避免這種行為。
水平對齊代碼會在代碼中增加壹些額外的空格，這使得相鄰兩行中的字符看起來像是在壹個垂直行上。
//壞
{
tiny: 42，
更長:435，
};
//很好
{
tiny: 42，
更長:435，
};避免使用const或let聲明所有局部變量。如果不需要重新分配變量，默認情況下應該使用const。應該拒絕關鍵字var。
不知道是因為沒人能說服他們，還是因為舊習難改。目前我還能看到很多人在StackOverFlow或者其他地方用var聲明變量。
//壞
var示例= 42；
//很好
const example = 42優先使用arrow函數arrow函數提供了簡潔的語法，避免了壹些關於這種指向的問題。相對於function關鍵字，開發者應該優先考慮使用箭頭函數來聲明函數，尤其是嵌套函數。
坦白說，我以為箭頭功能的作用只是簡潔美觀而已。但是現在我發現他們有壹個更重要的角色。
//壞
[1, 2, 3].地圖(函數(x) {
const y = x+1；
返回x * y；
});
//很好
[1, 2, 3].map((x)= & gt；{
const y = x+1；
返回x * y；
});使用模板字符串代替連接字符串在處理多行字符串時，模板字符串比復雜的拼接字符串表現更好。
//壞
函數sayHi(名稱){
返回“妳好嗎，”+ name +“？”；
}
//壞
函數sayHi(名稱){
返回['妳好，'，姓名，'？'].join()；
}
//壞
函數sayHi(名稱){
返回“妳好嗎，${ name }？`;
}
//很好
函數sayHi(名稱){
返回“妳好嗎，${name}？`;
}不要使用延續字符來拆分長字符串。在JS中，\也代表連續字符。Google的代碼規範不允許在模板字符串和普通字符串中都使用延續字符。盡管這在ES5中是允許的，但是如果壹些結束空格後面跟有\，這種行為將會導致壹些錯誤，在檢查代碼時很難註意到。
這個規則很有趣，因為在Airbnb的規範中有壹個不同的規則。
谷歌推薦以下寫法，而Airbnb則認為應該就這麽長，不需要特殊處理。
//壞(建議在PC端閱讀)
const longString = '這是壹個很長的字符串
遠遠超過了80列的限制。不幸的是
包含很長的空格，因為\
連續行縮進。；
//很好
const longString = '這是壹個很長的字符串'+
遠遠超過了80列的限制。它不包含'+
從連接的“+
琴弦更幹凈，”；用於第壹個...在ES6中，有三種不同的for循環。雖然每個應用場景都有自己的，但Google仍然推薦使用for...的。
有趣的是，Google應該特別指定壹個for循環。雖然這很奇怪，但並不影響我接受這個觀點。
我曾經認為...in適用於遍歷對象，而for...適合於遍歷數組。因為我喜歡這種工作方式。
雖然谷歌的規範與這種使用方式有沖突，但谷歌對for的偏好...的還是讓我覺得很有意思。
不要使用eval語句。除非在代碼加載器中，否則不需要使用eval或函數(...string)結構。此功能有潛在的危險，在CSP環境中不起作用。
MDN中有壹節特別提到不要使用eval語句。
//壞
讓obj = { a: 20，b:30 }；
let propName = get propName()；//返回“a”或“b”
eval( 'var result = obj '+propName)；
//很好
讓obj = { a: 20，b:30 }；
let propName = get propName()；//返回“a”或“b”
let result = obj[propName]；//Obj ["a"]是與obj.a常量相同的命名規範。常量的命名應該全部采用大寫格式，並用下劃線分隔。
如果妳確定壹個變量值以後不會被修改，妳可以用全大寫的方式重寫它的名字，暗示這是壹個常量，請不要修改它的值。
在觀察這個規則時需要註意的壹點是，如果這個常數是壹個函數，那麽應該使用駝峰命名法。
//壞
const number = 5；
//很好
const NUMBER = 5；壹次只聲明壹個變量，每個變量聲明應該只對應壹個變量。不應該出現像讓a = 1，b = 2；這樣的說法。
//壞
設a = 1，b = 2，c = 3；
//很好
設a = 1；
設b = 2；
設c = 3；使用單引號只允許單引號包圍普通字符串，禁止使用雙引號。如果字符串包含單引號字符，則應使用模板字符串。
//壞
let directive =“沒有自我或使命的認同。”
//壞
讓我們說不是這樣的。；
//很好
let directive = '沒有自我或使命的認同'；
//很好
讓我們說不是這樣。綜上所述，如我開頭所說，規範中沒有需要強制執行的命令。雖然谷歌是科技巨頭之壹，但這個代碼規範只是作為參考。
谷歌是壹家才華橫溢的技術公司，它雇傭優秀的程序員來編寫優秀的代碼。看到這樣的公司發布的代碼規範，很有意思。
如果妳想實現壹個Google風格的代碼，妳可以在項目中制定這些規範。但是妳可能不認同這個代碼規範，也沒有人會阻止妳放棄壹些規則。
我個人認為，在某些場景下，Airbnb的代碼規範比Google的代碼規範更好。但是不管妳支持哪壹個，寫什麽樣的代碼，最重要的是在妳的頭腦中始終遵守同壹個代碼規範。
相信看完這個案例，妳已經掌握了方法。更多精彩請關註Gxl上其他相關文章！
推薦閱讀:
如何用JS實現動態進度條
如何使用js+css實現打字效果