用空格還是用 Tab 鍵?谷歌推出《JavaScript 指南》,解答編程小白的問題

編者按:谷歌的程序員大大為了幫助剛入手JavaScript的小白們寫出乾淨、易懂的代碼,提供了一個獨具特色的教程《Java Script指南》,而本文作者丹尼爾西蒙斯,一位web開發人員/Java愛好者精心總結了谷歌推出的這份指南中最有趣、最有用的十三條規則。

JS具有強大的靈活性和包容性,因此,JS的編寫具有不同的風格,因此如何保證你的源程序在編寫過程中保持着統一的風格才是編寫JS的過程中需要注意的。

谷歌和Airbnb使用着兩種最流行的編寫規則,它們對細節的把控深深的影響着我,從一個個的標點到頁面的布局,扣着一個個的小細節,這也深深的影響了我在碼JS過程中的一些習慣。以下是我挑選的谷歌JS指南中最有趣、有用的十三條規則。

我將針對每一個規則都會給一個總體的敘述,然後再進行詳細的敘述,結合自身的開發經歷,給出一些實用的介紹,如果條件允許,還有一些相關的例子給大家分享一下。

用空格還是用Tab鍵?

除了行終止符之外,ASCII字符(0x20)是在源文件中出現的唯一空白字符。這意味着Tab製表符不用於縮進。

因此,你應該使用空格來實現你的設計而不是Tab製表符,而且只要鍵入兩個空格就可以,而不是四個空格。

// bad
function foo() {
∙∙∙∙let name;
}

// bad
function bar() {
∙let name;
}

// good
function baz() {
∙∙let name;
}

必不可少的分號

每個語句都必須以分號結束。不要為了省事使用自動分號插入。那會給你帶來後面很多不必要的麻煩的。

// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
 jedi.father = 'vader';
});

雖然我無法想象為什麼有人反對這個想法,但在JS中使用分號正在成為一種新的「空格與製表符」的爭論。谷歌是支持使用分號的,至於剛入行的小白還是建議跟着潮流走。

不要使用ES6模板

不要使用ES6模塊(即導出和輸入關鍵字),因為它們的語義還沒有最終確定。

// Don't do this kind of thing yet:
//------ 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';

中立態度的水平對齊

在谷歌提供的模板裡面,水平對齊並沒有提出很高的要求,還是比較隨意的。

水平對齊就是在目標模塊的周邊增加可變數量的額外空格,使得目標出現在我們想讓他出現的位置上就可以。

// bad
{
 tiny:   42,  
 longer: 435,
};// good
{
 tiny: 42,
 longer: 435,
};

不要使用var關鍵字

除非需要重新分配一個變量,否則將所有本地變量聲明為const關鍵字或let型。默認情況下使用const。但是在使用var關鍵字的時候一定要慎重。

其實在平時學習中,我仍然看到人們在StackOverflow和其他地方的代碼示例中使用var型。我不知道其他人使用var是因為什麼,可能這只是一種老習慣垂死掙扎吧。

// bad
var example = 42;// good
let example = 42;

首選箭頭

個人感覺箭頭函數已經提供了簡潔的語法,並解決了許多困難。所以個人更喜歡箭頭函數而不是函數關鍵字,特別是嵌套函數。

說實話,我認為箭頭不僅功能很好,而且它們更簡潔,更美觀。而且,事實證明,它們也有很重要的作用。

// 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}?`;
}

不要對長字符串使用行延續

在普通或模板字符串中不要使用行延續(也就是說,在字符串結尾以反斜杠結束一行字)。儘管ES5允許這樣做,但如果在斜杠之後出現任何尾隨空格,那麼它就會導致棘手的錯誤,而且對新手來說不太明顯。

// bad (sorry, this doesn't show up well on mobile)
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.';

有趣的是,這是谷歌和Airbnb意見不同的規則(這是Airbnb的規範)。雖然谷歌推薦連接更長的字符串(如下所示),但Airbnb的風格指南建議基本上什麼都不做,並且允許長字符串在需要的時候繼續使用。

「for…of」是「for循環」的首選類型

在ES6中,語言現在有三種不同的for循環。程序員是可以使用所有的循環,但在可能的情況下應該首選for-of循環。

我個人感覺for更適合於對象,而for of更適合於數組。只是適合不同的風格。雖然谷歌的規範並不一定與這個想法相矛盾,但是,可以看出谷歌對於這個循環還是情有獨鐘的。

不要使用eval()

不要使用eval或函數(…string)構造函數(代碼加載器除外)。這些特性可能是危險的,在CSP環境中根本不起作用。

eval()的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

常量應該以全部大寫命名,並且以下劃線分隔。

常量名稱使用類似於CONSTANT_CASE的表示方法:所有大寫字母,用下劃線隔開。

如果可以絕對確定變量不改變,就可以使用常量來定義,這樣也可以表示某個變量在整個過程中不會發生改變。

這個規則的一個特例就是,如果這個變量是函數特有的話,最好是申名在函數的空間裡面。

每個變量獨立對待

這沒有什麼好介紹的,直接上代碼:

// 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`;

最後的總結

正如我一開始所說的,這些不是唯一的標準。谷歌只是眾多科技巨頭中的一個,而這些只是眾多程序員總結出來的經驗而已。

看看谷歌這樣的公司提出的風格建議還是比較有意義的,它雇傭了很多聰明的人,他們花了大量時間研究如何編寫優秀的代碼。

如果你想遵循「谷歌兼容的源代碼」的指導方針,你可以遵循這些規則——但是,你要是有自己的喜好,那很棒,你可以自由地放飛自我。

我個人認為,在很多情況下,Airbnb的規範比谷歌更有吸引力。不過無論對這些特定的規則採取何種立場,我們在編寫任何類型的代碼時,唯一的要求就是要保持風格上的一致性。

文章來源:https://medium.freecodecamp.org/google-publishes-a-javascript-style-guide-here-are-some-key-lessons-1810b8ad050b

編譯組出品。編輯:郝鵬程



想在手機閱讀更多Javascript資訊?下載【香港矽谷】Android應用
分享到Facebook
技術平台: Nasthon Systems