1.1 格式化

關于縮進層次: 我不想挑起“Tab or Space”和“2 or 4 or 6 or 8 Space”的辯論，對這個話題是可以爭論上好幾個小時的，縮進甚至關系到程序員的價值觀。你只要記住以下三點：

代碼一定要縮進，保持對其。

不要在同一個項目中混用Tab和Space。

保持與團隊風格的統一。

關于結尾分號: 有賴于分析器的自動分號插入（Automatic Semicolon Insertion, ASI）機制，JS代碼省略分號也是可以正常工作的。ASI會自動尋找代碼中應當使用分號但實際沒有分號的位置，并插入分號。大多數場景下ASI都會正確插入分號，不會產生錯誤，但ASI的分號插入規則非常復雜且很難記住，因此我推薦不要省略分號。大部分的風格指南（除了JavaScript Standard Style）都推薦不要省略分號。

關于行的長度: 大部分的語言以及JS編碼風格指南都指定一行的長度為80個字符，這個數值來源于很久之前文本編輯器的單行最多字符限制，即編輯器中單行最多只能顯示80個字符，超過80個字符的行要么折行，要么被隱藏起來，這些都是我們所不希望的。我也傾向于將行長度限定在80個字符。

關于換行：當一行長度達到了單行最大字符限制時，就需要手動將一行拆成兩行。通常我們會在運算符后換行，下一行會增加兩個層次的縮進（我個人認為一個縮進也可以，但絕對不能沒有縮進）。例如：

callFunc(document, element, window, 'test', 100, true);

在這個例子中，逗號是一個運算符，應當作為前一行的行尾。這個換行位置非常重要，因為ASI機制會在某些場景下在行結束的位置插入分號。總是將一個運算符置于行尾，ASI就不會自作主張地插入分號，也就避免了錯誤的發生。這個規則有一個例外：當給變量賦值時，第二行的位置應當和賦值運算符的位置保持對齊。比如：

var result = something + anotherThing + yetAnotherThing + somethingElse +
 anotherSomethingElse;

這段代碼里，變量 anotherSomethingElse 和行首的 something 保持左對齊，確保代碼的可讀性，并能一眼看清楚折行文本的上下文。

關于空行：在編程規范中，空行是常常被忽略的一個方面。通常來講，代碼看起來應當像一系列可讀的段落，而不是一大段揉在一起的連續文本。有時一段代碼的語義和另一段代碼不相關，這時就應該使用空行將它們分隔，確保語義有關聯的代碼展現在一起。一般來講，建議下面這些場景中添加空行：

在方法之間。

在方法中的局部變量和第一條語句之間。

在多行或單行注釋之前。

在方法內的邏輯片段之間插入空行，提高可讀性。

1.2 命名

命名分變量、常量、函數、構造函數四類：其中變量和函數使用小駝峰命名法（首字母小寫），構造函數使用大駝峰命名法（首字母大寫），常量使用全大寫并用下劃線分割單詞。

let myAge; // 變量：小駝峰命名const PAGE_SIZE; // 常量：全大寫，用下劃線分割單詞function getAge() {} // 普通函數：小駝峰命名function Person() {} // 構造函數：大駝峰命名

為了區分變量和函數，變量命名應該以名字作為前綴，而函數名前綴應當是動詞（構造函數的命名通常是名詞）。看如下例子：

let count = 10; // Goodlet getCount = 10; // Bad, look like functionfunction getName() {} // Goodfunction theName() {} // Bad, look like variable

命名不僅是一門科學，更是一門技術，但通常來講，命名長度應該盡可能短，并抓住要點。盡量在變量名中體現出值的數據類型。比如，命名count、length和size表明數據類型是數字，而命名name、title和message表明數據類型是字符串。但用單個字符命名的變量諸如i、j和k通常在循環中使用。使用這些能夠體現出數據類型的命名，可以讓你的代碼容易被別人和自己讀懂。

要避免使用沒有意義的命名，如：foo、bar和tmp。對于函數和方法命名來說，第一個單詞應該是動詞，這里有一些使用動詞常見的約定：

動詞 含義

can 函數返回一個布爾值

has 函數返回一個布爾值

is 函數返回一個布爾值

get 函數返回一個非布爾值

set 函數用來保存一個值

1.3 直接量

JS中包含一些類型的原始值：字符串、數字、布爾值、null和undefined。同樣也包含對象直接量和數組直接量。這其中，只有布爾值是自解釋（self-explanatory）的，其他的類型或多或少都需要思考一下它們如何才能更精確地表示出來。

關于字符串：字符串可以用雙引號也可以用單引號，不同的JS規范推薦都不同， 但切記不可在一個項目中混用單引號和雙引號。

關于數字：記住兩點建議：第一，為了避免歧義，請不要省略小數點之前或之后的數字；第二，大多數開發者對八進制格式并不熟悉，也很少用到，所以最好的做法是在代碼中禁止八進制直接量。

// 不推薦的小數寫法：沒有小數部分let price = 10.;// 不推薦的小數寫法：沒有整數部分let price = .1;// 不推薦的寫法：八進制寫法已經被棄用了let num = 010;

關于null：null是一個特殊值，但我們常常誤解它，將它和undefined搞混。在下列場景中應當使用null。

用來初始化一個變量，這個變量可能賦值為一個對象。

用來和一個已經初始化的變量比較，這個變量可以是也可以不是一個對象。

當函數的參數期望是對象時，用作參數傳入。

當函數的返回值期望是對象時，用作返回值傳出。

還有下面一些場景不應當使用null。

不要使用null來檢測是否傳入了某個參數。

不要用null來檢測一個未初始化的變量。

理解null最好的方式是將它當做對象的占位符（placeholder）。這個規則在所有的主流編程規范中都沒有提及，但對于全局可維護性來說至關重要。

關于undefined：undefined是一個特殊值，我們常常將它和null搞混。其中一個讓人頗感困惑之處在于null == undefined結果是true。然而，這兩個值的用途卻各不相同。那些沒有被初始化的變量都有一個初始值，即undefined，表示這個變量等待被賦值。比如：

let person; // 不好的寫法console.log(person === undefined); // true

盡管這段代碼能正常工作，但我建議避免在代碼中使用undefined。這個值常常和返回"undefined"的typeof運算符混淆。事實上，typeof的行為也很讓人費解，因為不管是值是undefined的變量還是未聲明的變量，typeof運算結果都是"undefined"。比如：

// foo未被聲明let person;console.log(typeof person); // "undefined"console.log(typeof foo); // "undefined"

這段代碼中，person和foo都會導致typeof返回"undefined"，哪怕person和foo在其他場景中的行為有天壤之別(在語句中使用foo會報錯，而使用person則不會報錯)。

通過禁止使用特殊值undefined，可以有效地確保只在一種情況下typeof才會返回"undefined"：當變量為聲明時。如果你使用了一個可能(或者可能不會)賦值為一個對象的變量時，則將其賦值為null。

// 好的做法let person = null;console.log(person === null); // true

將變量初始值賦值為null表明了這個變量的意圖，它最終很可能賦值為對象。typeof運算符運算null的類型時返回"object"， 這樣就可以和undefined區分開了。

關于對象直接量和數組直接量: 請直接使用直接量語法來創建對象和數組，避免使用Object和Array構造函數來創建對象和數組。

1.4 注釋

注釋是代碼中最常見的組成部分。它們是另一種形式的文檔，也是程序員最后才舍得花時間去寫的。但是，對于代碼的總體可維護性而言，注釋是非常重要的一環。JS支持兩種注釋：單行注釋和多行注釋。

很多人喜歡在雙斜線后敲入一個空格，用來讓注釋文本有一定的偏移（我非常推薦你這么做）。單行注釋有三種使用方法：

獨占一行的注釋，用來解釋下一行代碼。這行注釋之前總是有一個空行，且縮進層級和下一行代碼保持一致。

在代碼行的尾部的注釋。代碼結束到注釋之間至少有一個縮進。注釋（包括之前的代碼部分）不應當超過最大字符數限制，如果超過了，就將這條注釋放置于當前代碼行的上方。

被注釋的大段代碼（很多編輯器都可以批量注釋掉多行代碼）。

單行注釋不應當以連續多行注釋的形式出現，除非你注釋掉一大段代碼。只有當需要注釋一段很長的文本時才使用多行注釋。

雖然多行注釋也可以用于注釋單行，但是我還是推薦僅在需要使用多行注釋的時候，才使用多行注釋。多行注釋一般用于以下場景：

模塊、類、函數開頭的注釋

需要使用多行注釋

我十分推薦你使用Java風格的多行注釋，看起來十分美觀，而且很多編輯器支持自動生成，見如下示例：

/**
 * Java風格的注釋，注意*和注釋之間
 * 有一個空格，并且*左邊也有一個空格。
 * 你甚至可以加上一些@參數來說明一些東西。
 * 例如：
 *
 * @author 作者
 * @param Object person
 */

何時添加注釋是程序員經常爭論的一個話題。一個通行的指導原則是， 當代碼不夠清晰時添加注釋，而當代碼很明了時不應當添加注釋。 基于這個原則，我推薦你在下面幾種情況下添加注釋：

難以理解的代碼： 難以理解的代碼通常都應當加注釋。根據代碼的用途，你可以用單行注釋、多行注釋，或者混用這兩種注釋。關鍵是讓其他人更容易讀懂這段代碼。

可能被誤認為錯誤的代碼： 例如這段代碼while(el && (el = el.next)) {}。在團隊開發中，總是會有一些好心的開發者在編輯代碼時發現他人的代碼錯誤，就立即將它修復。有時這段代碼并不是錯誤的源頭，所以“修復”這個錯誤往往會制造其他錯誤，因此本次修改應當是可追蹤的。當你寫的代碼有可能會被別的開發者認為有錯誤時，則需要添加注釋。

瀏覽器特性hack： 這個寫過前端的都知道，有時候你不得不寫一些低效的、不雅的、徹頭徹尾的骯臟代碼，用來讓低版本瀏覽器正常工作。

1.5 語句和表達式

關于 花括號的對齊方式 ，有兩種主要的花括號對齊風格。第一種風格是，將左花括號放置在塊語句中第一句代碼的末尾，這種風格繼承自Java；第二種風格是將左花括號放置于塊語句首行的下一行，這種風格是隨著C#流行起來的，因為Visual Studio強制使用這種對齊方式。當前并無主流的JS編程規范推薦這種風格，Google JS風格指南明確禁止這種用法，以免導致錯誤的分號自動插入。我個人也推薦使用第一種花括號對齊格式。

// 第一種花括號對齊風格if (condition) {
}// 第二種花括號對齊風格if (condition)
{
}

關于塊語句間隔: 有下面三種風格，大部分的代碼規范都推薦使用第二種風格：

// 第一種風格if(condition){
 doSomething();
}// 第二種風格if (condition) {
 doSomething();
}// 第三種風格if ( condition ) {
 doSomething();
}

關于switch語句，很多JS代碼規范都沒有對此做詳細的規定，一個是而實際工作中你也會發現使用場景比較少。因為你只有在有很多條件判斷的情況下才會用switch（短條件就直接用if語句了），但是熟練的程序員面對很多的判斷條件一般都會用對象表查詢來解決這個問題。看如下推薦的風格代碼：

switch (condition) { case 'cond1': case 'cond2':
 doCond1(); break; case 'cond3':
 doCond3(); break; default:
 doDefault();
}

推薦你遵循如下的風格：

switch后的條件括號需要前后各一個空格；

case語句需要相對switch語句縮進一個層級；

允許多個case語句共用一個處理語句；

如果沒有默認執行代碼，可以不用加default

關于with：JS引擎和壓縮工具無法對有with語句的代碼進行優化，因為它們無法猜出代碼的正確含義。在嚴格模式中，with語句是被明確禁止的，如果使用則報語法錯誤。這表明ECMAScript委員會確信with不應當繼續使用。我也強烈推薦避免使用with語句。

關于for循環：for循環有兩種，一種是傳統的for循環，是JS從C和Java中繼承而來，主要用于遍歷數組成員；另外一種是for-in循環，用來遍歷對象的屬性。

針對for循環， 我推薦盡可能避免使用continue，但也沒有理由完全禁止使用，它的使用應當根據代碼可讀性來決定。

for-in循環是用來遍歷對象屬性的。不用定義任何控制條件，循環將會有條不紊地遍歷每個對象屬性，并返回屬性名而不是值。for-in循環有一個問題，就是它不僅遍歷對象的實例屬性（instance property），同樣還遍歷從原型繼承來的屬性。當遍歷自定義對象的屬性時，往往會因為意外的結果而終止。出于這個原因，最好使用hasOwnProperty()方法來為for-in循環過濾出實例屬性。我也推薦你這么做，除非你確實想要去遍歷對象的原型鏈，這個時候你應該加上注釋說明一下。

// 包含對原型鏈的遍歷for (let prop in obj) { console.log(`key: ${prop}; value: ${obj[prop]}`);
}for (let prop in obj) { if (obj.hasOwnProperty(prop)) { console.log(`key: ${prop}; value: ${obj[prop]}`);
 }
}

關于for-in循環，還有一點需要注意，即for-in循環是用來遍歷對象的。一個常見的錯誤用法是使用for-in循環來遍歷數組成員，它的結果可能不是你想要的（得到的是數組下標），你應該使用ES6的for-of循環來遍歷數組。

let arr = ['a', 'b', 'c'];for (let i in arr) { console.log(i); // 0, 1, 2}for (let v of arr) { console.log(v); // 'a', 'b', 'c'}

1.6 變量聲明

我們知道JS中var聲明的變量存在變量提升，對變量提升不熟悉的同學寫代碼的時候就會產生不可意料的Bug。例如：

function func () { var result = 10 + result; var value = 10; return result; // return NaN}// 實際被解釋成function func () { var result; var value;
 result = 10 + result;
 value = 10; return result;
}

在某些場景中，開發者往往會漏掉變量提升，for語句就是其中一個常見的例子（因為ES5之前沒有塊級作用域）：

function func (arr) { for (var i = 0, len = arr.length; i < len; i += 1) {}
}// 實際被解釋成function func (arr) { var i, len; for (i = 0, len = arr.length; i < len; i += 1) {}
}

變量聲明提前意味著：在函數內部任意地方定義變量和在函數頂部定義變量是完全一樣的。 因此，一種流行的風格是將你所有變量聲明放在函數頂部而不是散落在各個角落。簡言之，依照這種風格寫出的代碼邏輯和JS引擎解析這段代碼的習慣是非常相似的。我也建議你總是將局部變量的定義作為函數內第一條語句。

function func (arr) { var i, len; var value = 10; var result = value + 10; for (i = 0; len = arr.length; i < len; i += 1) { console.log(arr[i]);
 }
}

當然，如果你有機會使用ES6，那我強烈推薦你完全拋棄var，直接用let和const來定義變量。相信我，拋棄var絕對值得的，let和const提供了塊級作用域，比var更安全可靠，行為更可預測。

1.7 函數聲明與調用

和變量聲明一樣，函數聲明也會被JS引擎提升。因此，在代碼中函數的調用可以出現在函數聲明之前。但是，我們推薦總是先聲明JS函數然后使用函數。此外，函數聲明不應當出現在語句塊之內。例如，這段代碼就不會按照我們的意圖來執行：

// 不好的寫法if (condition) { function func () {
 alert("Hi!");
 }
} else { function func () {
 alert("Yo!");
 }
}

這段代碼在不同瀏覽器中的運行結果也是不盡相同的。不管condition的計算結果如何，大多數瀏覽器都會自動使用第二個聲明。而Firefox則根據condition的計算結果選用合適的函數聲明。這種場景是ECMAScript的一個灰色地帶，應當盡可能地避免。函數聲明應當在條件語句的外部使用。這種模式也是Google的JS風格指南明確禁止的。

一般情況下，對于函數調用寫法推薦的風格是，在函數名和左括號之間沒有空格。這樣做是為了將它和塊語句區分開發。

// 好的寫法callFunc(params);// 不好的寫法，看起來像一個塊語句callFunc (params);// 用來做對比的塊語句while (condition) {}

1.8 立即調用的函數

IIFE(Immediately Invoked Function Expression)，意為立即調用的函數表達式，也就是說，聲明函數的同時立即調用這個函數。ES6中很少使用了，因為有模塊機制，而IIFE最主要的用途就是來模擬模塊隔離作用域的。下面有一些推薦的IIFE寫法：

// 不好的寫法：會讓人誤以為將一個匿名函數賦值給了這個變量var value = function () { return { msg: 'Hi'
 };
}();// 為了讓IIFE能夠被一眼看出來，可以將函數用一對圓括號包裹起來// 好的寫法var value = (function () { return { msg: 'Hi'
 };
}());// 好的寫法var value = (function () { return { msg: 'Hi'
 };
})();

1.9 嚴格模式

如果你在寫ES5代碼，推薦總是使用嚴格模式。不推薦使用全局的嚴格模式，可能會導致老的代碼報錯。推薦使用函數級別的嚴格模式，或者在IIFE中使用嚴格模式。

1.10 相等

關于JS的強制類型轉換機制，我們不得不承認它確實很復雜，很難全部記住（主要是懶）。所以我推薦你，任何情況下，做相等比較請用===和!==。

1.11 eval

動態執行JS字符串可不是一個好主意，在下面幾種情況中，都可以動態執行JS，我建議你應該避免這么做，除非你精通JS，并且知道自己在做什么。

eval("alert('bad')");const func = new Function("alert bad('bad')");
setTimeout("alert('bad')", 1000);
setInterval("alert('bad')", 1000);

1.12 原始包裝類型

JS裝箱和拆箱了解下，原始值是沒有屬性和方法的，當我們調用一個字符串的方法時，JS引擎會自動把原始值裝箱成一個對象，然后調用這個對象的方法。但這并不意味著你應該使用原始包裝類型來創建對應的原始值，因為開發者的思路常常會在對象和原始值之間跳來跳去，這樣會增加出bug的概率，從而使開發者陷入困惑。你也沒有理由自己手動創建這些對象。

// 自動裝箱const name = 'Nicholas';console.log(name.toUpperCase());// 好的寫法const name = 'Nicholas';const author = true;const count = 10;// 不好的寫法const name = new String('Nicholas');const author = new String(true);const count = new Number(10);

1.13 工具

團隊開發中，為了保持風格的統一，Lint工具必不可少。因為即使大家都明白要遵守統一的編程風格，但是寫代碼的時候總是不經意就違背風格指南的規定了（畢竟人是會犯錯的）。這里我推薦你使用ESLint工具進行代碼的風格檢查，你沒必要完全重新寫配置規則，你可以繼承已有的業內優秀的JS編碼規范來針對你團隊做微調。我這里推薦繼承自Airbnb JavaScript Style Guide，當然，你也可以繼承官方推薦的配置或者Google的JS編碼風格，其實在編碼風格上，三者在大部分的規則上是相同的，只是在一部分細節上不一致而已。

當然，如果你實在是太懶了，那了解一下JavaScript Standard Style，它是基于ESLint的一個JS風格檢查工具，有自己的一套風格，強制你必須遵守。可配置性沒有直接引入ESLint那么強，如果你很懶并且能夠接受它推薦的風格，那使用StandardJS倒也無妨。

相信看了本文案例你已經掌握了方法，更多精彩請關注Gxl網其它相關文章！

推薦閱讀：

使用JS實做出加密解密操作

js 數組操作與解析方法匯總

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com