我不能再忍受你的代碼風格了！——JSCS

Scott 發布于2019-08-19 18:13 / 2502人閱讀

摘要：從來沒有見過這么強大的代碼格式化和風格統一工具。你可以預設像等公司的代碼風格。所有工具的安裝辦法自動生成你的代碼風格的配置文件。學會的代碼規范，意味著你的代碼風格已經走在了世界第一行列。

無論人數多少，代碼都應該同出一門。

JavaScript 或者 Node 的語法本身很弱，在teamwork 和大型項目開發的時候，技術選型時往往選擇了 typescript 或者加入 Facebook 的 flow 工具。但是對于代碼風格，確實難以統一江山。

每個開發者會有自己的開發習慣，自己喜歡的編輯器，代碼風格更加是千差萬別。進入 Team work 之后，團隊管理的第一件事情就是定義規范，文件命名，目錄結構，代碼風格。就像這樣

然后會組織多次會議，一起學習研究規范, 一次又一次。然后在 code review 的時候指出，這里不符合規范，那邊命名有問題。時間久了，大家對于規范的印象和要求就弱了。如果有新員工入職，那他又得重新學一遍代碼風格規范，誰知道，新員工對團隊代碼風格接受和學習得怎么樣呢？代碼風格的問題一直困擾了很久。

當然我們也做了很多嘗試，比較加入 jshint、grunt 編譯的時候，執行 css、js 檢查。更加喪心變狂的是，加入了 .git/pre-commit ，在 git 提交的時候，必須通過預檢查，才能提交。這種方式過于粗暴，可配置的內容也不夠靈活。只能惡心一下自己，并沒有在開發團隊推廣起來。

來的不早也不晚，JSCS 恰巧就這樣出現了。從來沒有見過這么強大的代碼格式化和風格統一工具。

正如官方介紹：

JSCS is a code style linter/formatter for programmatically enforcing your style guide. You can configure JSCS for your project/company using over 150 validation rules, including presets from popular style guides like jQuery, Airbnb, Google, and more.

優點

JSCS 有超過150種代碼驗證規則。

你可以預設像 Google、Airbnb 等公司的代碼風格。

JSCS 可以幫你檢查，甚至按照你的預設風格格式化代碼。當執行 jscs app/ --fix 的時候，項目的代碼風格立馬和 Airbnb 保持一致了，我還像個沒見過世面的人一樣驚嘆了一番。

支持 ES2015, JSX, Flow 等。它可以驗證任何有效的 babel 代碼

支持絕大多數開發工具和環境。Grunt Task、Atom、Sublime Text、Intellij IDEA、WebStrom、RubyMine 等等。所有工具的安裝辦法

自動生成你的代碼風格的配置文件。jscs --auto-configure src 。比如：我的團隊代碼風格很牛掰，不需要引入其他的代碼風格，那這一行命令，就可以讓所有風格統一起來。

你要知道，Airbnb 的 javascript 代碼風格在 github 里有3.4W+ star。 https://github.com/airbnb/javascript

學會 Airbnb 的代碼規范，意味著你的代碼風格已經走在了世界第一行列。代碼功底沒到第一線，至少代碼風格提上來了，值得你裝逼了。少年，激動吧。

這份文檔涵蓋了 js 的所有方法面面，對于 web 開發再合適不過了。

上手安裝

npm install jscs -g

運行

jscs path[ path[...]]

你也可以注入到 JSCS

cat myfile.js | jscs

進階

開發工具可以自動讀取項目中的 .jscsrc 文件，來進行 JSCS 檢查，并且 格式化好你的代碼 。配置文件舉例：

{
  // 使用 jquery 編碼風格規范
  "preset": "airbnb",
  "fix": true,
  "maxErrors": 50,
  "fileExtensions": [".js", ".jsx"],
  "excludeFiles": []

  // 改變 requireCurlyBraces 規則
  //"requireCurlyBraces": null // or false

}

常用配置

preset （用預置規則進行規則預設）

fix (true|false) 是否自動修復風格

additionalRules （附加規則）

excludeFiles （對指定文件或目錄禁用風格檢查,默認排除 node_modules 文件夾）"excludeFiles": ["folder_to_exclude/**", "src/!(bar|foo)"]

fileExtensions （驗證文件后綴名） "fileExtensions": [".js", ".jsx"]

maxErrors （設置錯誤要報告的最大數目，默認50）

esnext 默認的。對于es2015的支持

es3 過時了，不要管了

verbose (true|false)（為有錯誤的信息添加規則名稱）

errorFilter （默認 false, 否則配置路徑）（確定是否報告錯誤的篩選器函數）

錯入容忍

你可以書寫默寫規則，讓 JSCS 容忍某些錯誤。所有的規則都可以在這里查到：http://jscs.info/rules

可以直接設置規則為 null ,

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

禁用所有規則

var a = b;

// jscs:disable
var c = d; // 在這行及之后的所有錯誤都將被忽略

// jscs:enable
var e = f; // 在這行及之后的所有錯誤都將被報告

禁用特定的規則

// jscs:disable requireCurlyBraces
if (x) y(); // 在這行及之后的所有 requireCurlyBraces 錯誤都將被忽略

// jscs:enable requireCurlyBraces
if (z) a(); // 在這行及之后的所有錯誤包括requireCurlyBraces 錯誤都將被報告

對單行進行特定規則忽略

 if (x) y(); // jscs:ignore requireCurlyBraces
 if (z) a();

禁用一個特定規則后，你可以啟用所有規則，該規則將重新啟用。

    // jscs:disable requireCurlyBraces
    if (x) y(); // 在這行及之后的所有 requireCurlyBraces 錯誤都將被忽略

    // jscs:enable
    if (z) a(); // 在這行及之后的所有錯誤包括 requireCurlyBraces 錯誤都將被報告

你可以同時禁用多個規則，并逐步重新啟用它們：

    // jscs:disable requireCurlyBraces, requireDotNotation
    if (x["a"]) y(); // 在這行及之后的所有 requireCurlyBraces 或 requireDotNotation 錯誤都將被忽略

    // jscs:enable requireCurlyBraces
    if (z["a"]) a(); // 在這行及之后的所有錯誤包括 requireDotNotation 錯誤都將被報告，但 requireCurlyBraces 錯誤將被忽略

    // jscs:enable requireDotNotation
    if (z["a"]) a(); // 在這行及之后的所有錯誤都將被報告

為某個文件禁用所有規則
在文件第一行寫上:

// jscs:disable

如果 JSCS 還不能滿足你和你團隊對代碼風格的要求，麻煩告知一個更好的辦法給我！

GPU云服務器云服務器購買了騰訊云如何再買域名代碼風格我大四了我明白了

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/79331.html

用什么工具保證一致的代碼風格？

摘要：目前來說基本上有四種工具可以完成，。發展歷程關于保持代碼一致性風格，我們可以追溯到。是啥是針對語言源碼的檢測工具，它的功能就是看看源碼有沒有編寫錯誤，有沒有風格問題。 1. 理解問題首先這個問題展開來講就是如何在Node.js模塊編寫中保持代碼一致性風格。目前來說基本上有四種工具可以完成JSLint，JSHint,JSCS,ESLint。下面將從歷史的角度來看看他們四個有什么關系...

linkin 2019-08-23 17:07 評論0 收藏0
【譯】JavaScript代碼檢查工具對比

摘要：看到很多團隊和開源項目都在用代碼檢查工具，自己一直沒用過，最近加入了新團隊有項目在用，就想著研究一下。代碼校驗工具能夠讓你在寫代碼時避免一些低級的錯誤。同時，也有友好的文檔針對每一條規則。在上文提高的所有工具當中它對有著最好的支持。看到很多團隊和開源項目都在用代碼檢查工具，自己一直沒用過，最近加入了新團隊有項目在用，就想著研究一下?？吹絪itepoint上的一篇2015年的文章覺得不...

fengxiuping 2019-08-20 18:10 評論0 收藏0
[譯]JavaScript lint工具的比較

摘要：工具幫助避免在編寫時出現愚蠢的錯誤。并不檢測潛在的，比如，未使用的變量或意外的全局變量等。在提到的所有工具中，它具有最廣泛的功能支持。使用工具是捕獲問題的良好步驟，但只能看到規則允許的錯誤。也可用于此目的。 Lint工具幫助避免在編寫JavaScript時出現愚蠢的錯誤。盡管有多年的經驗，我仍然鍵入不正確的變量名稱，出現語法錯誤，以及忘記正確地處理error。在浪費自己時間，或更糟糕地...

luck 2019-08-20 18:56 評論0 收藏0
一個靠譜的前端開源項目需要什么？

摘要：一個靠譜的應該包含以下幾部分言簡意賅的項目介紹你的項目解決了什么核心問題，有哪些令人心動的特性。除了在中提到遵循的開源協議外，一個靠譜的開源項目還會將該開源協議的內容文檔放在自己的項目下方。 0. 前言寫前端代碼一段時間之后，你可能會萌生做一個開源項目的想法，一方面將自己的好點子分享出去讓更多的人受益，另一方面也可以在社區貢獻的環境下學到更多的東西從而快速成長。但是開源項目也有開源項...

hiyayiji 2019-08-19 18:40 評論0 收藏0
一個靠譜的前端開源項目需要什么？

摘要：一個靠譜的應該包含以下幾部分言簡意賅的項目介紹你的項目解決了什么核心問題，有哪些令人心動的特性。除了在中提到遵循的開源協議外，一個靠譜的開源項目還會將該開源協議的內容文檔放在自己的項目下方。 0. 前言寫前端代碼一段時間之后，你可能會萌生做一個開源項目的想法，一方面將自己的好點子分享出去讓更多的人受益，另一方面也可以在社區貢獻的環境下學到更多的東西從而快速成長。但是開源項目也有開源項...

DesGemini 2019-05-29 16:57 評論0 收藏0