首先，這份 JS風格指南已經在我司的前端團隊實行半年多了；
其次，在程式設計師的世界裡，從入行到資深都需要面對幾個世界級的難題，如：

1. 世界上最好的編輯器是什麼？
2. 是用空格還是 TAB？用空格還特麼衍生出 2空格 VS 4空格。
3. JS到底要不要寫分號？
4. …

最後，PHP是世界上最好的語言。

一、規範VS自由

對程式設計師的每個個體來說，有程式碼規範其實不一定是好事，因為肯定會影響到寫碼的自由。
比如某程式設計師習慣用 Tab，團隊引入了某規範說都要換成 Spaces，這對於 Tab黨來說這不是“噩耗”麼。

尤其是對於老程式設計師，如果習慣多年的程式碼風格需要改變(先且不論好壞)，確實是件很擰巴的事情。

但是對整個團隊來說，有程式碼規範肯定是大好事。而且由於好處實在太多，比如方便管理、好維護、易閱讀等等，所以我也別一條條去羅列了，大家都懂:)

如果，某套程式碼規範甚至程式碼流程，能讓團隊中的成員都相對滿意，而且還能切實的去執行…我想說：請好好珍惜這美好的時光。

目前，各個大廠、各種開源專案都有多種 JS的寫法規範。今天本文介紹的 JS 規範號稱“Standard Style”，絕對是使用最廣的寫法之一(star 7800+)，而且有提供配套的工具、外掛可以方便的使用。

二、介紹“JS Standard Style”

standardjs就是這個這個專案的名稱。
對了，它的作者叫 Feross，建議程式設計師們去了解一下，你會知道程式設計師世界的“猛人”到底能有多凶殘。

請仔細看看這篇 JS規範要點，The Rules：

• 2 spaces – for indentation
• Single quotes for strings – except to avoid escaping
• No unused variables – this one catches tons of bugs!
• No semicolons – It’s fine. Really!
• Never start a line with (, [, or `
• This is the only gotcha with omitting semicolons – automatically checked for you!
• Space after keywords if (condition) { … }
• Space after function name function name (arg) { … }

• Always use === instead of == – but obj == null is allowed to check null

  undefined.

• Always handle the node.js err function parameter
• Always prefix browser globals with window – except document and navigator are okay
• Prevents accidental use of poorly-named browser globals like open, length, event, and name.
• And more goodness – give standard a try today!

沒錯，先不管這個規範帶來了多大的好處和優點，但是我標註的兩個條件確實有點要命：沒有分號；2空格。

有關是否有分號的討論可以寫許多篇論文了；
至於用 tab還是用空格…都可以引發程式設計師的聖戰啦。

所以這裡看看就好，想了解更多的同學，強烈建議你私下去搜索些更多資料。ps：為毛要私下搜尋？請參考下圖，我其實只是想為你的安全考慮:)

三、先簡單用起來！

官方的 demo 是使用 npm script 來展示的。一句話表述：先全域性安裝 standard這個包，然後使用 CLI是實現後續的操作和展示。

$ npm install standard –global

這種方式很適合用作 JS程式碼的校驗稽核。如下圖：

但是如果想配合日常開發用上，達到自動提醒，甚至自動格式化的程度，我非常推薦配合著對應的編輯器外掛來使用。

四、配合編輯器外掛

我喜歡和推薦這個規範的主要原因就是 —— 不用配置！
ps：如果你有了解過 ESLint，面對那各種各樣的 Configuring 和 Rules，特麼有幾個人能堅持去看完的，反正我是放棄了。

但是使用 standardjs，它已經把規則都定好了，所以如果你接受它的規則，那麼直接無腦使用就行了。如下圖：

支援 standardjs外掛的編輯器還是很多的，幾乎前端常用的編輯器都覆蓋到了：
Sublime Text、Atom、Vim、Emacs、Brackets、Visual Studio Code、WebStorm/PhpStorm。

篇幅有限，僅介紹下在 Atom編輯器下的使用和效果吧。Atom需要安裝對應的兩款外掛：

• linter-js-standard - Linter plugin for JavaScript Standard Style
• standard-formatter - Format file contents using JavaScript Standard Style

效果如下圖：

啊~這是個美好的時代。

五：如何在專案中實現統一的程式碼風格

不是每個程式設計師都有程式碼潔癖，也不是每個程式設計師都偏執的想寫好程式碼，更多的普通人其實只是想少折騰的把工作完成就好。
所以對於在團隊內推行程式碼規範這種事情，順其自然就好。

但是，使用以下這套方案可以讓這套規範推行的更順暢些。

第一步：專案中使用 ESLint，安裝對應的包：

• eslint
• eslint-config-standard
• eslint-plugin-promise
• eslint-plugin-standard

第二步：編輯器安裝對應外掛，以 Atom舉例：

• linter-js-standard
• linter
• linter-eslint
• standard-formatter

最後一步：在專案中增加的 .eslintrc，只需要一行即可

extends: standard

開發時自動格式化就這麼實現了，想想是不是還有點小激動呢。
ps：希望你有顆包容的心，因為在這半年來，我們也確實遇到了一些小問題，善用 stackoverflow 和開源專案對應的 Issue，各種問題你都能找到答案。

六、小結：聊幾句優、缺點

對著這套 JS規範本身，一直都在泛泛而談，優點和缺點的論述到處散落著，我在這簡單梳理下我個人理解吧。

有關優點：

• 閱讀程式碼的心情會變好 - 工作年限越長越能理解這句話的含義，這也是我最在意的一點，誰會有好心情去讀第一眼糟糕的程式碼；更沒有人願意去讀一個幾百行，但是有幾套程式碼風格的程式碼。
• 不用學習麻煩的 ESLint，無配置。
• 規範中有一條“No unused variables”沒有細說，但確實非常有用。未使用的變數會進行提示，方便你優化、縮減程式碼，甚至定位問題。
• 想一想，如果團隊有新人加入，不用過於擔心他的程式碼風格了，不管他的工作年限。
• 有套路、好維護。

有關缺點：

• 如果對“JS Standard Style”的某條規範有異議，能否去修改呢？答：不能。
• 會影響少數人自由。單方面會冒犯到其他程式設計師，比如 Tab黨、4空格黨。
• 我們全團隊使用 Atom，配合著對應的外掛，偶爾會有點小問題。萬能的 stackoverflow 和Issue 會幫助到我們。
• 對了，別被這套規範的名稱給騙了，這其實不是真正的 JS標準，真正的 JS標準現在還在討論的沒玩沒了呢。

以上就是我使用這套規範的感受吧。

最後，感謝已經離職的、優秀的德森同學(阿里花名“全棧”，我就問你們怕不怕)。是他強行在我們的 Nodejs Docker專案裡面加上了這套玩意，讓我們不得不用上了，哈哈哈哈哈哈哈哈。

這篇文章確實有點長了，那麼再長點也無所謂了吧，於是我找到了下面這幅圖…

七、看圖，講一個悲傷的故事

如果你沒有尷尬癌，強烈推薦你看這個圖片的出處 —— 《矽谷》。
真的很多搞笑的點只有程式設計師才能正確 Get。

就這樣，over.