前端代碼規範
多人協作開發過程中的代碼規範就顯得尤爲重要，並不是說統一之後規範一定就比規範外的語言規範就要好，目的是多人合作開發中統一了規範，代碼風格趨向統一。這樣在維護項目代碼的時候，與別人交接項目後減少溝通和時間成本。
前言
語言規範除了口頭約定，可以藉助工具來完成約束。工具可以是編輯器層的也可以是代碼層的。下面我的闡述我寫的語言規範會在在約定中儘量寫到我是怎麼遵守這些約定，有沒有藉助工具來實現。
正文
儘量基於主流的語言規範作爲一套統一的語言規範，然後基於上面進行改造，改造的過程中不能破壞語言的穩定性，易讀性。下文提到的編輯器工具插件都是基於vsCode來進行闡述。
註釋規範
可用工具：JSDOC插件(Document this)和vsCode自帶的用戶代碼片段。
開發者的註釋水平的先決條件是代碼命名和註釋能力，一個好的註釋應該讓別人一眼就能理解代碼的功能作用。jsdoc是前端普遍認可的代碼書寫規範。使用vscode的朋友可以使用js註釋插件Document this來完成註釋的模板創建，也可以使用vscode自帶的代碼片段來完成。也沒有什麼優劣之分，只是看個人愛好。
- JSDOC
- Vscode 代碼片段
有很多的開發者覺得個人寫的代碼很清晰很優雅，根本不用寫註釋。其實我個人觀點覺得代碼寫清晰註釋這個是基本要求。代碼優雅和使用了過多的語法糖之後相反會使別人難以理解。註釋本身就是代碼的組成部分。
同時也要避免爲了寫註釋而寫註釋，一個好的註釋不應該是沒有用的註釋，應該詳細描繪其描寫的功能函數參數的作用，目的，副作用，缺點，適用範圍。
單個文件行數限制
請限制單個文件代碼在300行。
-
限制方式：eslint
-
解決方法：模塊化、組件化
-
目的：代碼易讀性優雅型
max-lines: [“error”, {“max”: 300, “skipBlankLine”: false, “skipComments”: false}]
接口規範
RestFul Api —》 使用Post/Get
命名規範
約定
- 默認使用駝峯命名(addProject)
- 組件的命名首字母需要大寫
- css的class名同樣推薦使用駝峯命名法(由於Cssmodel的影響，不使用中橫線，同時也方便鼠標或者鍵盤取詞)
- 常量大寫
- 儘量全寫(使別人觀詞得義)
- 文件名都儘量小寫，然後使用下劃線作爲劃分詞義
可用工具
eslint,編輯器代碼風格工具Prettier.
推薦的話還是推薦eslint配合vscode保存修正。可以節省不少工作量，如果使用的Prettier，交接項目的時候，對方的電腦的Prettier使用的可能是自定義規則，出來的代碼風格又會出現差異。這個只能約束代碼層級的代碼風格，不過也夠了，eslint的代碼風格約束是現在主流的前端代碼語法檢測工具。
Eslint中文網 , 駝峯命名法可以使用eslint規則的camelcase來進行約束。
typescript
前端主流強類型方案。由vscode東家微軟開源方案，vscode內置支持，(微軟開源還是挺香的)。typescript對於我來說不只是代碼類型檢查工具，真正吸引我們的應該是其類型提示帶來的無數友好代碼提示，代碼都是有跡可循。2020年了，是時候試用typescript了。
typescript，檢查的代碼邏輯層的錯誤，約束的也是代碼邏輯層。
套用筆者同事的一句話，typescript，一路提示一路TAB,火車帶閃電，代碼寫好了。約束工具也是生產工具。
小結
以上，皆是筆者對於代碼規範進行的一些實踐和一些想法。開發前端到現在應該也有三個年頭，剛好碰上了前端的繁榮時代，所幸在時代的浪潮下接觸了這麼多有趣的東西。希望會越來越好。未完
