Google爲了(le)那些還(hái)不熟悉代碼規範的(de)人(rén)發布了(le)一個(gè)JS代碼規範。其中列出了(le)編寫簡潔易懂(dǒng)的(de)代碼所應該做(zuò)的(de)最佳實踐。
代碼規範并不是一種編寫正确JavaScript代碼的(de)規則,而是爲了(le)保持源代碼編寫模式一緻的(de)一種選擇。對(duì)于JavaScript語言尤其如此,因爲它靈活并且約束較少,允許開發者使用(yòng)許多(duō)不同的(de)編碼樣式。
Google和(hé)Airbnb各自占據著(zhe)當前最流行的(de)編碼規範的(de)半壁江山。如果你會在編寫JS代碼上投入很長(cháng)時(shí)間的(de)話(huà),我強烈推薦你通(tōng)讀一遍這(zhè)兩家公司的(de)編碼規範。
接下(xià)來(lái)要寫的(de)是我個(gè)人(rén)認爲在Google的(de)代碼規範中,與日常開發密切相關的(de)十三條規則。
它們處理(lǐ)的(de)問題都非常具有争議(yì)性,包括tab與空格、是否強制使用(yòng)分(fēn)号等等。還(hái)有一些令我感到驚訝的(de)規則,往往最後都改變了(le)我編寫JS代碼的(de)習(xí)慣。
對(duì)于每一條規則,我都會先給出規範的(de)摘要,然後引用(yòng)規範中的(de)詳細說明(míng)。我還(hái)會舉一些适當的(de)反例論證遵守這(zhè)些規則的(de)重要性。
除了(le)每一行的(de)終止符序列,ASCII水(shuǐ)平空格符(0x20)是唯一一個(gè)可(kě)以出現在源文件中任意位置的(de)空格字符。這(zhè)也(yě)意味著(zhe),tab字符不應該被使用(yòng),以及被用(yòng)來(lái)控制縮進。
規範随後指出應該使用(yòng)2個(gè),而不是4個(gè)空格帶實現縮進。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
|
每個(gè)語句必須以分(fēn)号結尾。不允許依賴于JS自動添加分(fēn)号的(de)功能。
盡管我不明(míng)白爲什(shén)麽會有人(rén)反對(duì)這(zhè)個(gè)規則,但目前分(fēn)号的(de)使用(yòng)問題顯然已經像“空格 vs tab”這(zhè)個(gè)問題一樣産生了(le)巨大(dà)的(de)争議(yì)。而Google對(duì)此表示分(fēn)号是必須的(de),是不可(kě)省略的(de)。
1
2
3
4
5
6
7
8
9
10
|
// 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模塊的(de)語義尚不完全确定,所以暫時(shí)不要使用(yòng),比如export和(hé)import關鍵字。一旦它們的(de)相關規範制定完成,那麽請忽略這(zhè)一條規則。
1
2
3
4
5
6
7
8
9
10
11
|
// 暫時(shí)不要編寫下(xià)面的(de)代碼:
//------ 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';
|
譯者注:感覺遵守這(zhè)條規範不大(dà)現實,畢竟現在已經有babel了(le)。而且使用(yòng)React時(shí),最佳實踐就是使用(yòng)ES6模塊吧。
Google的(de)代碼規範允許但不推薦對(duì)代碼進行水(shuǐ)平對(duì)齊。即使之前的(de)代碼中做(zuò)了(le)水(shuǐ)平對(duì)齊的(de)處理(lǐ),以後也(yě)應該避免這(zhè)種行爲。
對(duì)代碼進行水(shuǐ)平對(duì)齊會在代碼中添加若幹多(duō)餘的(de)空格,這(zhè)讓相鄰兩行的(de)字符看上去處于一條垂直線上。
1
2
3
4
5
6
7
8
9
10
|
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
|
使用(yòng)const或let來(lái)聲明(míng)所有局部變量。如果變量不需要被重新賦值,默認應該使用(yòng)const。應該拒絕使用(yòng)關鍵字var。
我不知道是因爲沒有人(rén)能說服他(tā)們,還(hái)是說因爲舊(jiù)習(xí)難改。目前我仍能看到許多(duō)人(rén)在StackOverFlow或其他(tā)地方使用(yòng)var聲明(míng)變量。
1
2
3
4
|
// bad
var example = 42;
// good
const example = 42;
|
箭頭函數提供了(le)一種簡潔的(de)語法,并且避免了(le)一些關于this指向的(de)問題。相比較與function關鍵字,開發者應該優先使用(yòng)箭頭函數來(lái)聲明(míng)函數,尤其是聲明(míng)嵌套函數。
坦白說,我曾以爲箭頭函數的(de)作用(yòng)隻在于簡潔美(měi)觀。但現在我發現原來(lái)它們還(hái)有更重要的(de)作用(yòng)。
1
2
3
4
5
6
7
8
9
10
11
|
// 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;
});
|
在處理(lǐ)多(duō)行字符串時(shí),模闆字符串比複雜(zá)的(de)拼接字符串要表現的(de)更出色。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
// 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}?`;
}
|
在JS中,
也(yě)代表著(zhe)續行符。Google的(de)代碼規範不允許在不管是模闆字符串還(hái)是普通(tōng)字符串中使用(yòng)續行符。盡管ES5中允許這(zhè)麽做(zuò),但如果在
後跟著(zhe)某些結束空白符,這(zhè)種行爲會導緻一些錯誤,而這(zhè)些錯誤在審閱代碼時(shí)很難注意到。
這(zhè)條規則很有趣,因爲Airbnb的(de)規範中有一條與之不相同的(de)規則
Google推薦下(xià)面這(zhè)樣的(de)寫法,而Airbnb則認爲應該順其自然,不做(zuò)特殊處理(lǐ),該多(duō)長(cháng)就多(duō)長(cháng)。
1
2
3
4
5
6
7
8
9
10
|
// bad (建議(yì)在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.';
|
for...of
在ES6中,有3種不同的(de)for循環。盡管每一種有它的(de)應用(yòng)場(chǎng)景,但Google仍推薦使用(yòng)
for...of
。
真有趣,Google居然會特别指定一種for循環。雖然這(zhè)很奇怪,但不影(yǐng)響我接受這(zhè)一觀點。
以前我認爲for...in
适合遍曆Object,而for...of
适合遍曆數組。因爲我喜歡這(zhè)種各司其職的(de)使用(yòng)方式。
盡管Google的(de)規範與這(zhè)種使用(yòng)方式相沖突,但Google對(duì)for...of
的(de)偏愛(ài)依然讓我覺得(de)十分(fēn)有趣。
除非是在code loader中,否則不用(yòng)使用(yòng)eval或是Function(…string)結構。這(zhè)個(gè)功能具有潛在的(de)危險性,并且在CSP環境中無法起作用(yòng)。
MDN中有一節專門提到不要使用(yòng)eval語句。
1
2
3
4
5
6
7
8
|
// 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
|
常量命名應該使用(yòng)全大(dà)寫格式,并用(yòng)下(xià)劃線分(fēn)割
如果你确定一定以及肯定一個(gè)變量值以後不會被修改,你可(kě)以将它的(de)名稱使用(yòng)全大(dà)寫模式改寫,暗示這(zhè)是一個(gè)常量,請不要修改它的(de)值。
遵守這(zhè)條規則時(shí)需要注意的(de)一點是,如果這(zhè)個(gè)常量是一個(gè)函數,那麽應該使用(yòng)駝峰式命名法。
1
2
3
4
|
// bad
const number = 5;
// good
const NUMBER = 5;
|
每一個(gè)變量聲明(míng)都應該隻對(duì)應著(zhe)一個(gè)變量。不應該出現像
let a = 1,b = 2;
這(zhè)樣的(de)語句。
1
2
3
4
5
6
|
// bad
let a = 1, b = 2, c = 3;
// good
let a = 1;
let b = 2;
let c = 3;
|
隻允許使用(yòng)單引号包裹普通(tōng)字符串,禁止使用(yòng)雙引号。如果字符串中包含單引号字符,應該使用(yòng)模闆字符串。
1
2
3
4
5
6
7
8
|
// bad
let directive = "No identification of self or mission."
// bad
let saying = 'Say it ainu0027t so.';
// good
let directive = 'No identification of self or mission.';
// good
let saying = `Say it ain't so`;
|
公司名稱:武漢互赢網絡科技有限公司
公司地址:武漢市武昌區(qū)靜安路6号創意産業園408室
客 服QQ:562257562 848467306
咨詢電話(huà):027-89992189
業務熱(rè)線:15972109576
公司網站:www.whtlnet.com
武漢做(zuò)網站 武漢網站建設 武漢網站制作 武漢網絡公司 武漢網站開發 武漢建網站
最新動态
常見問題百寶箱
A2014,有位學妹不顧家人(rén)反對(duì),在上海這(zhè)個(gè)國際化(huà)大(dà)都市謀了(le)一個(gè)公衆号助理(lǐ)的(de)職位。鬥志昂揚地奮鬥了(le) 3 年,我眼看著(zhe)她的(de)内容駕馭能力突飛(fēi)猛進,内容質量從三流到一流,職位
A文章(zhāng)主要分(fēn)析了(le)不同的(de)視覺設計元素是如何影(yǐng)響網站用(yòng)戶體驗,希望通(tōng)過文章(zhāng)的(de)解讀能夠對(duì)你的(de)産品設計帶來(lái)些啓發。 也(yě)許是因爲我在視覺設計上沒有太多(duō)經驗,我發現
A雙赢系統建站系統,三網同步,建站推廣一步到位雙赢系統建站系統,三網同步,建站推廣一步到位雙赢系統建站系統,三網同步,建站推廣一步到位雙赢系統建站系統,三網同步,建站推
Copyright 2013-2020 All Rights Reserved 雲南雲豹網絡科技股份有限公司