首先這個問題展開來說就是"如何在Node.js
模塊編寫中保持代碼一致性風格"。前端
目前來講基本上有四種工具能夠完成JSLint
,JSHint
,JSCS
,ESLint
。程序員
下面將從歷史的角度來看看他們四個有什麼關係,以及選用建議。編程
關於保持代碼一致性風格,咱們能夠追溯到Lint
。工具
Lint
是啥?Lint
是針對C語言源碼的檢測工具,它的功能就是看看源碼有沒有編寫錯誤,有沒有風格問題。編碼
啥是編寫錯誤呢?插件
編寫錯誤就意味着上考場沒帶准考證,別說考的好很差,根本沒機會考。code
編寫錯誤意味着你的代碼根本通不過編譯。繼承
啥是風格問題呢?開發
風格問題能夠比喻爲上考場穿着三角褲衩,雖然本身考的挺嗨,可是影響別人發揮(光看你的內褲啥顏色了)。編譯器
好了,既然C語言有這樣的工具,那麼咱們JS語言有沒有這樣的工具呢?
答案是確定的,按照時間順序,JS語言界依次出現四位大咖:JSLint
,JSHint
,JSCS
,ESLint
。
JSLint
做爲開山鼻祖,它不只能夠檢測代碼編寫錯誤,還能夠檢測代碼風格問題。
可是它的斷定規則徹底按照JSLint的做者經驗來制定,不容許改變,大有信我者昌,逆我者亡的氣勢。
這樣作,在檢查代碼編寫錯誤時是沒問題的,可是檢查代碼風格時候就有點尷尬,
好比有的公司就喜歡讓員工穿褲衩上班,由於這樣程序員能夠快樂編程,可是用了你這款工具,程序員只能穿西服編碼,大大下降寶寶們的編程效率,可惡可惡。
因而,JSHint
就出現啦。
JSHint
是JSLint
的繼承者,它繼承JSLint
擁有的規則,可是它容許經過配置文件來配置這些規則。
可是吧,還不夠完全,雖然他容許我配置規則,可是不容許我自定義規則。
就好比,原先在JSLint
中,有這樣一條規則:"禁止員工穿褲衩上班",
如今JSHint中將這條規則轉化爲"[禁止]員工穿褲衩上班",同時容許你在配置文件配置方框號中的內容,並且只能配置爲[容許]和[禁止]
可是假如我想制定一條規則是"[禁止]員工穿拖鞋上班",JSHint
就不支持啦,因此仍是有點不盡興。
不過,什麼事情都難不倒的程序員,JSCS如約而至。
JSCS
自己超過90條的規則,可是任然容許制定新的規則,好比"[禁止]員工穿拖鞋上班",嗯,忽然以爲好知足。
但...JSCS
僅僅支持代碼風格檢查,不能檢查編寫錯誤問題,爲啥呢,我也不知道,也許做者以爲編寫檢查能夠直接交給編譯器?
天將降大任於斯人也,吸取前人的經驗,彌補前人的不足,ESLint
在衆人期待中出現了。
ESLint
支持檢查編寫錯誤問題,支持檢查代碼風格問題,支持制定自定義規則,支持經過配置文件修改預約義和自定義規則。
完美,終於能夠愉快的生活啦,哈哈哈哈...
ESLint功能豐富,除了上面說的這些基礎功能,還有不少不少,並且前端開發鏈條上的其餘插件也願意和ESLint配合。總之,ESLint出現坑,有人會填,其餘的出現坑,只能本身跳進去填,因此,聽從你心裏的選擇吧。