關于Google發(fā)布的JavaScript代碼規(guī)范你要知道哪些
Google為了那些還不熟悉代碼規(guī)范的人發(fā)布了一個JS代碼規(guī)范。其中列出了編寫簡潔易懂的代碼所應該做的最佳實踐。
代碼規(guī)范并不是一種編寫正確JavaScript代碼的規(guī)則,而是為了保持源代碼編寫模式一致的一種選擇。對于JavaScript語言尤其如此,因為它靈活并且約束較少,允許開發(fā)者使用許多不同的編碼樣式。
Google和Airbnb各自占據著當前最流行的編碼規(guī)范的半壁江山。如果你會在編寫JS代碼上投入很長時間的話,我強烈推薦你通讀一遍這兩家公司的編碼規(guī)范。
接下來要寫的是我個人認為在Google的代碼規(guī)范中,與日常開發(fā)密切相關的十三條規(guī)則。
它們處理的問題都非常具有爭議性,包括tab與空格、是否強制使用分號等等。還有一些令我感到驚訝的規(guī)則,往往最后都改變了我編寫JS代碼的習慣。
對于每一條規(guī)則,我都會先給出規(guī)范的摘要,然后引用規(guī)范中的詳細說明。我還會舉一些適當的反例論證遵守這些規(guī)則的重要性。
使用空格代替tab
除了每一行的終止符序列,ASCII水平空格符(0x20)是唯一一個可以出現在源文件中任意位置的空格字符。這也意味著,tab字符不應該被使用,以及被用來控制縮進。
規(guī)范隨后指出應該使用2個,而不是4個空格帶實現縮進。
// bad function foo() { ∙∙∙∙let name; } // bad function bar() { ∙let name; } // good function baz() { ∙∙let name; }
不能省略分號
每個語句必須以分號結尾。不允許依賴于JS自動添加分號的功能。
盡管我不明白為什么會有人反對這個規(guī)則,但目前分號的使用問題顯然已經像“空格 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關鍵字。一旦它們的相關規(guī)范制定完成,那么請忽略這一條規(guī)則。
// 暫時不要編寫下面的代碼: //------ 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';
譯者注:感覺遵守這條規(guī)范不大現實,畢竟現在已經有babel了。而且使用React時,最佳實踐就是使用ES6模塊吧。
不推薦代碼水平對齊
Google的代碼規(guī)范允許但不推薦對代碼進行水平對齊。即使之前的代碼中做了水平對齊的處理,以后也應該避免這種行為。
對代碼進行水平對齊會在代碼中添加若干多余的空格,這讓相鄰兩行的字符看上去處于一條垂直線上。
// 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;
優(yōu)先使用箭頭函數
箭頭函數提供了一種簡潔的語法,并且避免了一些關于this指向的問題。相比較與function關鍵字,開發(fā)者應該優(yōu)先使用箭頭函數來聲明函數,尤其是聲明嵌套函數。
坦白說,我曾以為箭頭函數的作用只在于簡潔美觀。但現在我發(fā)現原來它們還有更重要的作用。
// 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}?`; }
不要使用續(xù)行符分割長字符串
在JS中,\也代表著續(xù)行符。Google的代碼規(guī)范不允許在不管是模板字符串還是普通字符串中使用續(xù)行符。盡管ES5中允許這么做,但如果在\后跟著某些結束空白符,這種行為會導致一些錯誤,而這些錯誤在審閱代碼時很難注意到。
這條規(guī)則很有趣,因為Airbnb的規(guī)范中有一條與之不相同的規(guī)則
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.';
優(yōu)先使用for...of
在ES6中,有3種不同的for循環(huán)。盡管每一種有它的應用場景,但Google仍推薦使用for...of。
真有趣,Google居然會特別指定一種for循環(huán)。雖然這很奇怪,但不影響我接受這一觀點。
以前我認為for...in適合遍歷Object,而for...of適合遍歷數組。因為我喜歡這種各司其職的使用方式。
盡管Google的規(guī)范與這種使用方式相沖突,但Google對for...of的偏愛依然讓我覺得十分有趣。
不要使用eval語句
除非是在code loader中,否則不用使用eval或是Function(...string)結構。這個功能具有潛在的危險性,并且在CSP環(huán)境中無法起作用。
MDN中有一節(jié)專門提到不要使用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
常量的命名規(guī)范
常量命名應該使用全大寫格式,并用下劃線分割
如果你確定一定以及肯定一個變量值以后不會被修改,你可以將它的名稱使用全大寫模式改寫,暗示這是一個常量,請不要修改它的值。
遵守這條規(guī)則時需要注意的一點是,如果這個常量是一個函數,那么應該使用駝峰式命名法。
// 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`;
總結
就像我在開頭所說那樣,規(guī)范中沒有需要強制執(zhí)行的命令。盡管Google是科技巨頭之一,但這份代碼規(guī)范也僅僅是用來當作參考罷了。
Google是一家人才匯聚的科技公司,雇傭著出色的程序員來編寫優(yōu)秀的代碼。能夠看到這樣的公司發(fā)布的代碼規(guī)范是一件很有趣的事情。
如果你想要實現一種Google式的代碼,那么你可以在項目中制定這些規(guī)范。但你可能并不贊成這份代碼規(guī)范,這時也沒有人會阻攔你舍棄其中某些規(guī)則。
我個人認為在某些場景下,Airbnb的代碼規(guī)范比Google的代碼規(guī)范要出色。但不管你支持哪一種,也不管你編寫的是什么類型的代碼,最重要的是在腦海中時刻遵守著同一份代碼規(guī)范。
總結
以上所述是小編給大家介紹的關于Google發(fā)布的JavaScript代碼規(guī)范你要知道哪些,希望對大家有所幫助,如果大家有任何疑問請給我留言,小編會及時回復大家的。在此也非常感謝大家對腳本之家網站的支持!
相關文章
webpack-url-loader 解決項目中圖片打包路徑問題
這篇文章主要介紹了webpack-url-loader 解決項目中圖片打包路徑問題,小編覺得挺不錯的,現在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2019-02-02js 獲取后臺的字段 改變 checkbox的被選中的狀態(tài) 代碼
js 獲取后臺的字段 改變 checkbox的被選中的狀態(tài) 代碼,需要的朋友可以參考一下2013-06-06