資訊專欄INFORMATION COLUMN
摘要：公司不同，規范的內容形式檢查方式也不同，但最終是要驗收你的規范。你的代碼不合規范，提交都提交不上去，這樣就能從入口上保證代碼的規范性。
背景
越來越多的前端項目開始使用typescript這門靜態檢查語言了，它包括很多很棒的功能點，在這里就不細述，根據靜態語法檢查和.d.ts生成的代碼提示兩大特性，我們就可以來制定并且檢查代碼規范，現在我們來詳細說一下。
代碼規范代碼規范大家應該是從開始寫第一行代碼開始別人就開始和你說，要遵循xx代碼規范。公司不同，規范的內容、形式、檢查方式也不同，但最終是要驗收你的規范。
如果是通過leader code review方式來檢查代碼，那效率也就太低了，最好的方式就是在GIT提交之前做檢查。你的代碼不合規范，提交都提交不上去，這樣就能從入口上保證代碼的規范性。
我們再說看下前端的代碼規范情況，前端的代碼主要就是js的代碼，因為js的靈活性以及隨意性，讓工具來檢查代碼的規范成為不可能，這也是我一直頭疼的事，因為規范這種東西，說再多遍，不來點強制手段，組內之前也是不可能達成一致的。直到Typescript的出現，解決了這個問題。
Typescript是javascript的超集，所以ts在運行之前，得先編譯成js，那么這個編譯的過程，ts的編譯引擎就得知道，文件里包括哪些方法，方法包含哪些參數，各參數的定義是什么，類型是什么，總之，所有源信息必須都知道，才能準確無誤的把ts翻譯成js。這些東西也正是我們需要的，通過這些信息，我們就可以對比規范和源信息，來確認是否是符合我們制定規范的代碼。
初步實現順著這個思路，我查了查typescript的官方文檔，果然找到了一個，叫做Compiler API，最后的那個例子，是和我們的需求相關的，把代碼拿下來，也是可以跑通的，所以呢，下一步，就是基于這個例子進行擴展，來滿足我們自己的需求。
實現的過程，也是挺痛苦的，因為沒有文檔，也沒有說明，幸虧在vscode可以點進行看聲明文件，好消息是可以看到方法的定義，壞消息就是所有的方法的聲明、類型，都沒有注釋，部分需要自己來猜，哈哈，有總比沒有強，照貓畫虎，總算實現了基本功能。
官方的.d.ts大致就長這樣
開發之中，有一個問題比較難解決，就是在目前可觀測的API中，只能constructor可以取到返回值類型，其他方法API根本不提供，最后借助stackoverflow上提問，解決了這個問題，有興趣的同學可以參考下：how to use typescript Compiler API to get normal function info, eg: returnType/parameters?
檢查你的代碼現在已經可以檢查你的代碼了，我們上面也說了，最好的檢查時機是開發人員提交的時候，這時會檢查所有的代碼，只有所有的代碼都符合規范，才會提交成功，這是我們最理想的情況。
按照這個思路，我們可以查到，Git有很多鉤子，pre-commit、commit-msg、post-commit等等，我們使用pre-commit：提交前檢查，會執行.git/hooks/pre-commit下的腳本文件，但是這個文件分布在組內所有人的筆記本中，并且不能增加版本控制。帶著這樣的疑問，我們找到了pre-commit這個神器，它的實現原理也是修改上面的文件，不過它從node層屏蔽了實現細節，我們只要在package.json里面增加一個script就可以實現我們要的功能。
配置大概是這樣：
...
"pre-commit": ["commit"],
"script":{
...
"commit": "ts-node verify.ts"
...
}
...
這樣在git里面commit（不管使用命令行還是SourceTree這樣圖形界面）的時候就會執行ts-node verify.ts，檢查要是失敗了，就會把錯誤信息打印到控制臺上，并且提交會失敗，直到所有的已定規則都驗證通過，才會提交成功。
檢查失敗，大致就是這樣的：
還有一個更大的作用我們已經通過上一步，能夠檢查我們的規范了，知道代碼的所有信息，比如生成.d.ts文件！對一個對外提供的工具庫來講，如果沒有一套完整的.d.ts文件進行代碼提示的話，那就顯的太不專業了。如果要生成一個完整的提示文件，就必須要求你的類、方法、參數、返回值都要有完整的注釋，這些就應該在你的代碼規范中。
我們來看一下，比較好的例子：
知道了所有的信息，生成這個文件其實就是字符串的拼接，沒什么技術含量，不過生成的格式還得注意一下。
兼容所有情況的.d.ts寫法一般我們使用一個庫文件的時候，都會有三種用法：
import Util from "xxx/Util"
import {DateTime, Fiel} from "xxx/Util"
import * as Util from "xxx/Util"
在使用的時候，這三種形式所需要的.d.ts文件的格式也是不一樣的，所以作為對外提供服務的庫文件來說，所有的使用方式，我們都應該兼容。經過多次嘗試，這樣格式的.d.ts文件是兼容所有用法：
export class DateTime {
static dateFormat(....)
}
declare const exDe: {
DateTime: typeof DateTime
}
export default exDe
源碼
Demo的源碼以及使用效果，用力點我
Demo中用到的代碼檢查工具，用力點我
檢查失敗的情況
檢查成功的情況
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/107269.html
摘要：對于項目的編碼規范而言，主要有兩種選擇和。此外由于性能問題，官方決定全面采用，甚至把倉庫作為測試平臺，而的解析器也成為獨立項目，專注解決雙方兼容性問題。最近在我的項目的編碼規范中全量的用代替了針對其中遇到的問題做一個記錄。 ??對于Typescript項目的編碼規范而言，主要有兩種選擇ESLint和TSLint。ESLint不僅能規范js代碼，通過配置解析器，也能規范TS代碼。此外由...
摘要：對于項目的編碼規范而言，主要有兩種選擇和。此外由于性能問題，官方決定全面采用，甚至把倉庫作為測試平臺，而的解析器也成為獨立項目，專注解決雙方兼容性問題。最近在我的項目的編碼規范中全量的用代替了針對其中遇到的問題做一個記錄。 ??對于Typescript項目的編碼規范而言，主要有兩種選擇ESLint和TSLint。ESLint不僅能規范js代碼，通過配置解析器，也能規范TS代碼。此外由...
摘要：對于項目的編碼規范而言，主要有兩種選擇和。此外由于性能問題，官方決定全面采用，甚至把倉庫作為測試平臺，而的解析器也成為獨立項目，專注解決雙方兼容性問題。最近在我的項目的編碼規范中全量的用代替了針對其中遇到的問題做一個記錄。 ??對于Typescript項目的編碼規范而言，主要有兩種選擇ESLint和TSLint。ESLint不僅能規范js代碼，通過配置解析器，也能規范TS代碼。此外由...
閱讀 1924·2021-11-19 09:40
閱讀 2132·2021-10-09 09:43
閱讀 3294·2021-09-06 15:00
閱讀 2810·2019-08-29 13:04
閱讀 2766·2019-08-26 11:53
閱讀 3512·2019-08-26 11:46
閱讀 2320·2019-08-26 11:38
閱讀 390·2019-08-26 11:27
