1. 程式人生 > >JavaScript必備:Google發布的JS代碼規範(轉)

JavaScript必備:Google發布的JS代碼規範(轉)

變量 分割 log join() 發布 感覺 之前 出現 urn

[翻譯]關於Google發布的JS代碼規範,你需要了解什麽?

翻譯 | WhiteYin

譯文 | https://github.com/WhiteYin/translation/issues/10

Google為了那些還不熟悉代碼規範的人發布了一個JS代碼規範。其中列出了編寫簡潔易懂的代碼所應該做的最佳實踐。

代碼規範並不是一種編寫正確JavaScript代碼的規則,而是為了保持源代碼編寫模式一致的一種選擇。對於JavaScript語言尤其如此,因為它靈活並且約束較少,允許開發者使用許多不同的編碼樣式。

Google和Airbnb各自占據著當前最流行的編碼規範的半壁江山。如果你會在編寫JS代碼上投入很長時間的話,我強烈推薦你通讀一遍這兩家公司的編碼規範。

接下來要寫的是我個人認為在Google的代碼規範中,與日常開發密切相關的十三條規則。

它們處理的問題都非常具有爭議性,包括tab與空格、是否強制使用分號等等。還有一些令我感到驚訝的規則,往往最後都改變了我編寫JS代碼的習慣。

對於每一條規則,我都會先給出規範的摘要,然後引用規範中的詳細說明。我還會舉一些適當的反例論證遵守這些規則的重要性。

使用空格代替tab

除了每一行的終止符序列,ASCII水平空格符(0x20)是唯一一個可以出現在源文件中任意位置的空格字符。這也意味著,tab字符不應該被使用,以及被用來控制縮進。

規範隨後指出應該使用2個,而不是4個空格帶實現縮進。

  1. // bad

  2. function foo() {

  3. ????let name;

  4. }

  5. // bad

  6. function bar() {

  7. ?let name;

  8. }

  9. // good

  10. function baz() {

  11. ??let name;

  12. }

不能省略分號

每個語句必須以分號結尾。不允許依賴於JS自動添加分號的功能。

盡管我不明白為什麽會有人反對這個規則,但目前分號的使用問題顯然已經像“空格 vs tab”這個問題一樣產生了巨大的爭議。而Google對此表示分號是必須的,是不可省略的。

  1. // bad

  2. let luke = {}

  3. let leia = {}

  4. [luke, leia].forEach(jedi => jedi.father = ‘vader‘)

  5. // good

  6. let luke = {};

  7. let leia = {};

  8. [luke, leia].forEach((jedi) => {

  9. jedi.father = ‘vader‘;

  10. });

暫時不要使用ES6 module

由於ES6模塊的語義尚不完全確定,所以暫時不要使用,比如export和import關鍵字。一旦它們的相關規範制定完成,那麽請忽略這一條規則。

  1. // 暫時不要編寫下面的代碼:

  2. //------ lib.js ------

  3. export function square(x) {

  4. return x * x;

  5. }

  6. export function diag(x, y) {

  7. return sqrt(square(x) + square(y));

  8. }

  9. //------ main.js ------

  10. import { square, diag } from ‘lib‘;

譯者註:感覺遵守這條規範不大現實,畢竟現在已經有babel了。而且使用React時,最佳實踐就是使用ES6模塊吧。

不推薦代碼水平對齊

Google的代碼規範允許但不推薦對代碼進行水平對齊。即使之前的代碼中做了水平對齊的處理,以後也應該避免這種行為。

對代碼進行水平對齊會在代碼中添加若幹多余的空格,這讓相鄰兩行的字符看上去處於一條垂直線上。

  1. // bad

  2. {

  3. tiny: 42,

  4. longer: 435,

  5. };

  6. // good

  7. {

  8. tiny: 42,

  9. longer: 435,

  10. };

杜絕var

使用const或let來聲明所有局部變量。如果變量不需要被重新賦值,默認應該使用const。應該拒絕使用關鍵字var。

我不知道是因為沒有人能說服他們,還是說因為舊習難改。目前我仍能看到許多人在StackOverFlow或其他地方使用var聲明變量。

  1. // bad

  2. var example = 42;

  3. // good

  4. const example = 42;

優先使用箭頭函數

箭頭函數提供了一種簡潔的語法,並且避免了一些關於this指向的問題。相比較與function關鍵字,開發者應該優先使用箭頭函數來聲明函數,尤其是聲明嵌套函數。

坦白說,我曾以為箭頭函數的作用只在於簡潔美觀。但現在我發現原來它們還有更重要的作用。

  1. // bad

  2. [1, 2, 3].map(function (x) {

  3. const y = x + 1;

  4. return x * y;

  5. });

  6. // good

  7. [1, 2, 3].map((x) => {

  8. const y = x + 1;

  9. return x * y;

  10. });

使用模板字符串取代連接字符串

在處理多行字符串時,模板字符串比復雜的拼接字符串要表現的更出色。

  1. // bad

  2. function sayHi(name) {

  3. return ‘How are you, ‘ + name + ‘?‘;

  4. }

  5. // bad

  6. function sayHi(name) {

  7. return [‘How are you, ‘, name, ‘?‘].join();

  8. }

  9. // bad

  10. function sayHi(name) {

  11. return `How are you, ${ name }?`;

  12. }

  13. // good

  14. function sayHi(name) {

  15. return `How are you, ${name}?`;

  16. }

不要使用續行符分割長字符串

在JS中, \也代表著續行符。Google的代碼規範不允許在不管是模板字符串還是普通字符串中使用續行符。盡管ES5中允許這麽做,但如果在 \後跟著某些結束空白符,這種行為會導致一些錯誤,而這些錯誤在審閱代碼時很難註意到。

這條規則很有趣,因為Airbnb的規範中有一條與之不相同的規則

Google推薦下面這樣的寫法,而Airbnb則認為應該順其自然,不做特殊處理,該多長就多長。

  1. // bad (建議在PC端閱讀)

  2. const longString = This is a very long string that \

  3. far exceeds the 80 column limit. It unfortunately \

  4. contains long stretches of spaces due to how the \

  5. continued lines are indented.‘;

  6. // good

  7. const longString = ‘This is a very long string that ‘ +

  8. ‘far exceeds the 80 column limit. It does not contain ‘ +

  9. ‘long stretches of spaces since the concatenated ‘ +

  10. ‘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語句。

  1. // bad

  2. let obj = { a: 20, b: 30 };

  3. let propName = getPropName(); // returns "a" or "b"

  4. eval( ‘var result = obj.‘ + propName );

  5. // good

  6. let obj = { a: 20, b: 30 };

  7. let propName = getPropName(); // returns "a" or "b"

  8. let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

常量的命名規範

常量命名應該使用全大寫格式,並用下劃線分割

如果你確定一定以及肯定一個變量值以後不會被修改,你可以將它的名稱使用全大寫模式改寫,暗示這是一個常量,請不要修改它的值。

遵守這條規則時需要註意的一點是,如果這個常量是一個函數,那麽應該使用駝峰式命名法。

  1. // bad

  2. const number = 5;

  3. // good

  4. const NUMBER = 5;

每次只聲明一個變量

每一個變量聲明都應該只對應著一個變量。不應該出現像 leta=1,b=2;這樣的語句。

  1. // bad

  2. let a = 1, b = 2, c = 3;

  3. // good

  4. let a = 1;

  5. let b = 2;

  6. let c = 3;

使用單引號

只允許使用單引號包裹普通字符串,禁止使用雙引號。如果字符串中包含單引號字符,應該使用模板字符串。

  1. // bad

  2. let directive = "No identification of self or mission."

  3. // bad

  4. let saying = ‘Say it ain\u0027t so.‘;

  5. // good

  6. let directive = ‘No identification of self or mission.‘;

  7. // good

  8. let saying = `Say it ain‘t so`;

總結

就像我在開頭所說那樣,規範中沒有需要強制執行的命令。盡管Google是科技巨頭之一,但這份代碼規範也僅僅是用來當作參考罷了。

Google是一家人才匯聚的科技公司,雇傭著出色的程序員來編寫優秀的代碼。能夠看到這樣的公司發布的代碼規範是一件很有趣的事情。

如果你想要實現一種Google式的代碼,那麽你可以在項目中制定這些規範。但你可能並不贊成這份代碼規範,這時也沒有人會阻攔你舍棄其中某些規則。

我個人認為在某些場景下,Airbnb的代碼規範比Google的代碼規範要出色。但不管你支持哪一種,也不管你編寫的是什麽類型的代碼,最重要的是在腦海中時刻遵守著同一份代碼規範。

JavaScript必備:Google發布的JS代碼規範(轉)