摘要：在團(tuán)隊開發(fā)過程中，我們可能會要浪費一些時間在代碼檢查上，譬如拼寫的檢查代碼規(guī)范的檢查。安裝及使用是一個用于代碼靜態(tài)檢查的一些開源項目。如果沒有指定文件，是不會對文件就行檢查的。

在團(tuán)隊開發(fā)過程中，我們可能會要浪費一些時間在代碼檢查上，譬如拼寫的檢查、代碼規(guī)范的檢查。作為碼農(nóng)，我們當(dāng)然不能把自己的時間浪費這種無意義的事情上，所以本篇我將介紹一些自動化代碼檢查的東西和項目實際上的應(yīng)用。

JSHint是一個用于JavaScript代碼靜態(tài)檢查的一些開源項目。他是運行與node環(huán)境，可以對我們指定的JavaScript文件進(jìn)行一些靜態(tài)的語法分析，譬如：變量定義、拼寫檢查、代碼風(fēng)格的檢查等，而且檢查項是靈活可配置的，可以針對不同項目的要求配置相應(yīng)的檢查項。JSHint使用方式有多種，他可以通過命令行、node_module、集成到IDE這些方式來執(zhí)行。在IDE中主要是通過插件的形式來使用，大家在自己順手的IDE上搜JSHint的插件來使用，接下來我主要講一下在命令行中使用和以node_module結(jié)合gulp使用。

我們可以通過npm安裝JSHint。這里需要注意的一些問題，如果我們?nèi)职惭bJSHint他是包含了CLI和JavaScript module的，如果是本地安裝則只包含JavaScript module。關(guān)于node中CLI和JavaScript module分別是怎么用的我后續(xù)再填坑，有興趣的可以自己去了解先。

因為我這里要測試命令行中使用，所以我們?nèi)职惭b。然后就可以通過jshint filename來對制定的文件進(jìn)行檢查了。

rem 全局安裝
npm i jshint -g

rem 本地安裝
npm i jshint

前面我們已經(jīng)知道如何對我們指定的文件進(jìn)行檢查了，但是他檢查的規(guī)則是什么呢？JSHint會去解析一個.jshintrc文件來確定如何檢查，這個文件是個json格式的配置文件，我們可以配置一些制定項來定制我們的檢查計劃。里面具體的配置選項可以上官網(wǎng)上查找。

{
    "undef": true
}

這里需要注意的是JSHint查找這個.jshintrc文件規(guī)則，會有多種情況：我們可以在我們命令后加上--config filename來執(zhí)行讀取對應(yīng)配置文件進(jìn)行檢查。另外，我們可以在項目中package.json文件的jshintConfig來配置我們的.jshintrc文件路徑。如果上面兩種都沒有配置的話，則是會按JShint默認(rèn)的規(guī)則來查找配置文件：JSHint會在當(dāng)前目錄查找是否有.jshintrc文件，如果沒有找到則向文件夾上一層查找，一直到查到.jshintrc文件或者根目錄為止。如果沒有指定.jshintrc文件，JSHint是不會對文件就行檢查的。

除了上面這種將檢查項配置在.jshintrc文件的方式外，我們還可以直接以注釋的形式將我們的檢查配置寫在我們的文件中。如下，如果我們的文件中有這樣的注釋，我們對該文件進(jìn)行檢查就會對未定義的變量進(jìn)行檢查。我們在代碼文件中增加jshint配置并不會終止查找.jshintrc文件讀取配置的流程，只是如果代碼文件中和.jshintrc有相同的配置時代碼文件中的配置會更高。

/* jshint undef: true */

your code

如果我們在項目中有些文件來自第三方，這些文件不要求尊求我們的規(guī)范，我們就需要將這些文件排除在我們的檢查列表之外，這時我們就需要另外一個配置文件.jshintignore。這個文件主要用于配置哪些文件不用于JSHint的檢查，里面可以放具體的文件名或者文件夾名（該目錄下都不被檢查）。

node_module
app/test.js

在項目中我們肯定不會用命令挨個檢查文件是否符合規(guī)范，所以我們通常會配合gulp這類自動化工具來做這些重復(fù)的事情。由于gulp是基于“流”的形式來處理的，所以我們無法直接使用JSHint，我們需要安轉(zhuǎn)一個gulp-jshint，然后就可以在我們的gulp任務(wù)中加入JSHint的檢查了。下面我們羅列一個簡單的使用JSHint檢查app路徑下所有JS文件的示例代碼。

var gulp = require("gulp");
var JSHint = require("gulp-jshint");

gulp.task("checkCode", function(){
    return gulp.src("./app/**/*.js")
    .pipe(JSHint())
    .pipe(JSHint.reporter("default"));
});

JSHint檢查的結(jié)果是通過命令行輸出的，我們可以使用.pipe(JSHint.reporter("default"))來使用默認(rèn)的樣式輸出檢查結(jié)果，為了增強(qiáng)可讀性，我們通常還會使用jshint-stylish來對結(jié)果進(jìn)行美化。

另外提下在某些情況下我們要檢查的js代碼可能位于其他類型文件內(nèi)（如HTML、JSX等），我們可以通過配置來實現(xiàn)。還有就是自定義一個reporter而不是使用JSHint.reporter。這些都可以通過查找文檔來了解具體的操作步驟。

以上我們就已經(jīng)實現(xiàn)了使用gulp自動對項目文件進(jìn)行規(guī)范檢查，但是我們不想手動的去執(zhí)行這個gulp任務(wù)，應(yīng)該手動的話肯定就有人會偷懶了。所以我們考慮可以把checkcode任務(wù)集成到編譯任務(wù)，因為前面都已經(jīng)用到了gulp了，說明我們的項目肯定是會需要構(gòu)建才能調(diào)試的，所以我們可以把checkCode任務(wù)集成進(jìn)去。但是這樣做有個缺點，我們的構(gòu)建任務(wù)通常會是一個高頻任務(wù)，但是checkCode任務(wù)肯定會是一個耗時的任務(wù)，而且項目穩(wěn)定之后checkCode檢查出的問題應(yīng)該是很少的，所以這樣做我們的時間浪費是不值得的，所以我們就得考慮把checkCode集成到一個低頻的操作中去。這時就是我們的git-hooks登場了。

通常我們都會使用svn/git這類工具對我們的代碼進(jìn)行管理，除了我們常用的那些pull/push功能，我們還可以利用他們提供的hooks來在特定的操作中加入我們自己的操作，比如我們這里將要用到的pre-commithook就能在代碼commit之前執(zhí)行我們預(yù)設(shè)的腳本。因為現(xiàn)在比較流行g(shù)it，所以我們接下的方案將是基于git來做的。

我們通過git init或者git clone創(chuàng)建一個git項目時，會在項目頂層目錄中生成一個.git文件夾（隱藏的），里面就包含了我們的一些git的配置信息，我們要了解的hooks就位于hooks目錄下。文件夾內(nèi)放置了很多hook的模板，不過這些.sample后綴的文件是不能識別的，想讓他們執(zhí)行只要去掉后綴即可。這里的提供的hooks只是客戶端的hook，在server端也有一些hook，可以去這里查找全部hook的信息和用法。示例中的hook是用shell寫的，但是他是支持Ruby或者Python來寫的。

下面我參考以前同事的pre-commit的腳本，具體內(nèi)容不再敘述。

#!/bin/sh

#執(zhí)行g(shù)ulp任務(wù)，并將結(jié)果輸出到臨時文件
gulp checkCode | tee check.log

#檢查gulp的check任務(wù)是否執(zhí)行失敗
if grep "warning" check.log || grep "error" check.log
then
echo -e "