3.4 使用Lint規范代碼

為了規范代碼，我們需要諸如TSLint及CSSLint類型的代碼掃描工具。我們可以利用這些Lint工具，通過配置語法檢測規則來對代碼風格進行檢測。也可以關閉所有的規則，只運行基本語法驗證，這一切都取決于我們的意圖。

對于代碼風格來說，有太多需要規范的地方，比如下面這些事項：

◎ 是否以分號（;）結束語句。

◎ 縮進四個空格，還是兩個空格。

◎ 判斷是否相等的時候，使用===，以避免類型轉換。

◎ 函數大括號是否換行。

通常，我們可以生成自己的配置選項，也可以使用其他團隊、組織創建好的風格配置。比如，Airbnb創建的eslint-config-airbnb規范，對于編寫JavaScript的人來說就相當不錯。我們可以在它的基礎上修改出符合要求的規范，從而節省大量的時間。

這些風格問題很難討論出一個好壞，但是我們需要統一成一種風格——如果在一個文件里，有的以兩個空格做縮進，有的以四個空格做縮進，那么它的閱讀體驗就會相當差。

幸運的是，在現有的前端應用模板里，都會生成相應的Lint配置。我們只需要在構建時、提交時、測試時運行相應的腳本，即可對代碼進行Lint掃描。不同組織有不同的使用傾向，特別是在那些有一定年代的系統、公司里，要改變現有的命名方式很難。因為使用哪種方式并不重要，重要的是保持一致。

事實上，這些Lint工具不僅能幫助我們分析代碼風格，還對代碼質量起著一定的監督作用。如在TSLint里，當我們繼承了一個類，但是沒有實現其方法時，它就會提醒我們這里有問題（筆者在這里使用的工具是WebStorm），代碼如圖3-2所示。

AppComponent類想實現OnInit接口，但是卻缺少ngOnInit屬性。另外，在諸如TypeScript這樣的靜態語言里，它能進行更細致的語法檢測。

當然，這些工具在提升質量的同時，也在一定程度上限制了代碼的靈活性，畢竟，靈活性和規范是難以兼得的。