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實現打字效果