讓我們看一看 @feross 的 JavaScript 標準風格 ，這是一個流行的 JavaScript 風格指南。它可以幫助你減少團隊之間的摩擦，增加程式設計師的幸福感。

這是 一組規則 ，可以使 JavaScript 程式碼更加一致 ，並且可以防止類似於 tabs縮排 和 空格縮排優缺點這一類無聊的話題討論。你可以採用多種風格之一，並且與其他 （如 JSLint ， JSHint 和 ESLint ）是同一種類型的 JavaScript 檢測器。

風格的重要性

如果你已經從事編碼工作有一段時間了的話，那你肯定會有一種自己喜歡的風格。當你成百上千次以特定的模式編寫程式碼時，你會發現你的編碼方式是令人愉悅的。突然間來了個人，開始把掛在行尾的大括號單起一行。你可能會發牢騷。深呼吸冷靜思考一下，你放置括號的位置 或 關鍵字後加空格 不會讓你的程式更加正確，這只是個人喜好。

每種程式語言都有一種主流編碼風格，比如像 Python，官方提供的 風格指南 被認為是編寫程式的正確方式。那麼你是否還會繼續討厭縮排用4個空格的人呢？（愚人碼頭注：Python 官方提供的風格指南，建議使用4個空格縮排）。

用主流風格進行編碼將有助於你的程式更能適應語言的生態環境。您還會發現，如果您熟悉該語言的主流編碼風格，並且一開始就同意這種編碼風格，那麼您可以更容易地為開源專案貢獻程式碼，同樣也更容易讓其他人來為你的開源專案貢獻程式碼。

JavaScript 沒有官方的編碼風格指南，或許 Douglas Crockford 的 The Good Parts 是一個實際上的標準。他的書（愚人碼頭注：《JavaScript 語言精粹》）提供了一種編寫可靠的方法來 JavaScript 程式，他強調了我們應該積極避免的某些特性。他釋出了 JSLint 來支援這些觀點，而其他的檢查工具也緊隨其後。大多數的檢查工具是高度可配置的，讓你選擇最適合你自己的風格，並將其強加於別人或團隊！JavaScript Standard Style(愚人碼頭注：這個專案名，所以沒翻譯，意思為 JavaScript 標準編碼風格) 則不同。你最喜歡的編碼風格無關緊要，重要的是，任何選擇都可以讓每個人理解和合作。

採用 standard 編碼風格意味著 程式碼清晰性和社群約定的重要性要高於個人的編碼風格。這不一定適用於所有專案和開發文化，但是開放專案原始碼對於新手來說可能非常不適應。建立清晰的、自動的編碼風格，滿足貢獻者期望可以使專案發展更健康。

如果你正在為自己編寫一個程式，沒有其他人需要為你做貢獻，那就使用那些讓你最快樂的工具和編碼風格。當你在一個團隊中工作時，你應該儘量減少摩擦，保持專業，不要因為小事而浪費太多的時間。

在介紹自己的風格之前，花點時間學習現有程式碼庫的風格。

JavaScript Standard Style （JavaScript 標準編碼風格）

• 使用兩個空格 – 進行縮排
• 字串使用單引號 – 需要轉義的地方除外
• 不再有冗餘的變數 – 這是導致 大量 bug 的源頭!
• 無分號 – 這裡有3篇文章說明不用分號的好處：文章1 文章2 文章3
• 行首不要以 (, [, or ` 開頭
• 這是省略分號時唯一會造成問題的地方 – 工具裡已加了自動檢測！
• [詳情][4]
• 關鍵字後加空格 if (condition) { ... }
• 函式名後加空格 function name (arg) { ... }
• 堅持使用全等 === 摒棄 == 一但在需要檢查 null || undefined 時可以使用 obj == null。
• 一定要處理 Node.js 中錯誤回撥傳遞進來的 err 引數。
• 使用瀏覽器全域性變數時加上 window 字首 – document 和 navigator 除外
• 避免無意中使用到了這些命名看上去很普通的全域性變數， open, length,
  event 還有 name。

最有爭議的規則無疑是不用分號。多年來人們一直認為，始終使用分號是避免錯誤的最佳實踐，Crockford 做了很多工作來促進這一點，使用封號有很深的根源，在 C 語言裡，分號是嚴格要求的，否則程式不會執行。

JavaScript Standard Style(JavaScript 標準編碼風格) 改變了我的想法，不用分號的 JavaScript 非常好。

分號自動插入是 JavaScript 的一個特性，它可以減少噪點、簡化程式，我從來沒有遇到過由於缺少分號而導致的bug，我也不相信你會遇到。檢視 JavaScript 中有必需使用分號的嗎? 以瞭解更多。

並不是所有人都同意，forks semistandard 和 happiness 有點唱反調，強調使用分號。我發現這些 forks 有點傷感，因為它們錯過忽略了整個標準的要點。

如果我不同意某條規則，可以改嗎？

不行。制定這套 standard 規範的目的就是讓大家都不必再花時間浪費在無謂的程式碼風格之爭上面了。關於縮排該用製表符還是空格這個問題已經爭論了很久了，永遠也沒有答案。爭論這個都可以把需求提前寫完了。遵循 standard 規範，你就不用再猶豫了，畢竟不管怎樣爭論總歸會選擇一種風格的。希望大家也能在個人語義和普適價值上做一個權衡。

就我個人而言，我已經開始喜歡不使用分號的編碼風格了，也許是因為需要編寫 Ruby、Python 和 CoffeeScript 的緣故，這些都不使用分號的語法。無論什麼原因，當看不到分號的時候，我發現程式更清晰了。

良好的程式層次結構

程式設計師應該重視：

1. 正確性
2. 可讀性
3. 幸福感
4. 高效率

事實證明，採用 JavaScript Standard Style(JavaScript 標準編碼風格)，對以上每一條都有好處。

正確性

在所有程式中使用的任何東西，都必須做你想要的，並且沒有錯誤。

編碼風格並不會使程式更正確，但是在釋出之前，檢查工具可以幫你捕獲一些錯誤。

可讀性

作為一個專業的開發人員，除了提供一份能正常執行的程式程式碼之外，程式碼的可讀性是最重要的。閱讀和嘗試理解程式比編寫程式碼要花費更多的精力和時間，因此請為未來的自己和維護程式碼的其他人進行可讀性優化。

清晰可預測的風格使程式碼更容易閱讀和理解。

程式設計師的幸福感

我喜歡 JavaScript Standard Style(JavaScript 標準編碼風格) 的原因之一是，它把重點放在人而不是機器上。程式設計師的幸福感在這個列表中排名第三的唯一原因是團隊合作中更需要可讀性，功能程式碼的正確性應該放在我們自己的幸福感之前，這是毋庸置疑的。

你想享受生活，不是嗎？如果你很快就能完成工作，而且你的工作又有趣，那不就是我們想要的享受生活嗎？這在一定程度上就是我們生活的目的。你的生活會更加美好。

– Yukihiro Matsumoto （愚人呢碼頭注：松本行弘是一位日本電腦科學家和程式設計師。他是Ruby程式設計語言的主要設計者和實現者。）

人生苦短，不能因個人偏好的不同而引起意見分歧，設定一個標準並後續推進不是更好嗎？如果一個標準的編碼風格能夠避免團隊之間的分歧和摩擦，那麼你就會更快樂。

高效率

列在最後，但並非最不重要。

如果你必須在這些要點上進行權衡，那麼你應該更加重視程式碼正確性、可讀性，並且使程式設計師對快速編寫程式碼感到愉悅。

計算機處理速度很快。如果程式高效，那就沒事了。如果您發現效能不佳，請花時間尋找效能瓶頸並使程式碼更高效。

人類處理問題的速度相對來說很慢。讓事情變得更有效率對我們來說更有價值。採用一種標準編碼風格的清晰性使您的程式碼能夠更快地理解並貢獻程式碼。花在分歧上的時間也少了很多，這是最受歡迎的。

實施 JavaScript Standard Style(JavaScript 標準編碼風格)

你可以不用任何工具就可以採用這個標準，只要通讀一下 規則 就可以，特別注意哪些和你以前習慣不同的規則。嘗試一個星期，看看你是否喜歡。如果你不是特別反感，那就用它吧！

還有一個 npm 包，用於檢查你的JavaScript程式碼。

1. npm install standard --global

通過這個檢測器，執行 standard 將執行目錄中的所有 JavaScript 檔案。

此外，還有所有常見的 文字編輯器外掛 ，這裡是如何在 Atom 中安裝檢測器。

1. apm install linter
2. apm install linter-js-standard

就我個人而言，當你正在輸入程式碼的時候，自動列印風格警告提示會讓你分心。如果你有同樣的感覺，在你完成工作後，再來檢查會更好。JavaScript 標準編碼風格 命令也有一個自動修復某些風格錯誤的 flag，這可能會節省一些時間。

1. standard --fix

採用 JavaScript Standard Style(JavaScript 標準編碼風格)

你應該採用 JavaScript Standard Style(JavaScript 標準編碼風格) 嗎？那麼這完全取決於你。

如果你沒有合適的風格指南，那就準備好面對分歧和衝突吧。

如果你已經完善了一套理想的規則，並希望在整個程式碼庫中執行它，那麼 ESLint 可能就是你最好的選擇。

如果你不想浪費時間在無聊的語法細節上，那就請用JavaScript Standard Style(JavaScript 標準編碼風格) 吧，歡迎評論說出你的想法。