讀 Angular 代碼風格指南
本文寫于 2021 年 1 月 17 日
原文地址：Angular 檔案
該文章擁有完整的代碼風格指南——大到如何編排檔案夾，小到如何進行變數命名都涉及，但是與 ng 略有系結，所以這里整理一下可以單獨拿出來的通用部分，
單一職責
請堅持每個檔案只定義一樣東西（例如服務或組件），并且把檔案大小限制在 400 行代碼以內，
小檔案通常非常容易閱讀、維護，并能防止在版本控制系統里與團隊沖突，
小檔案還可以防止一些隱蔽的程式缺陷，當把多個組件合寫在同一個檔案中時，可能造成共享變數、創建意外的閉包，或者與依賴之間產生意外耦合等情況，
總的來說，單一職責原則可以讓代碼更加可復用、更容易閱讀，減少出錯的可能性，
如果該檔案是一個函式，那么請堅持定義簡單函式，并且限制在 75 行之內，
這樣能更便于我們做單元測驗，
命名
命名是一件非常重要的事情，他可以讓其他人看我們的代碼，或者是我們自己在一段時間之后再看之前的代碼時，可以迅速理解檔案內容、變數含義、方法用途……，也可以在全域搜索的時候，讓我們可以迅速定位到目標，
代碼給人讀的時間比給機器讀的時間多多了，因此我們需要慎重考慮命名，
可以遵循以下兩個原則：
- 堅持使用一致的命名規則；
- 堅持遵循同一個模式來描述特性和型別，
檔案命名
ng 推薦使用點和橫杠來分隔檔案名——在描述性名字中，用橫杠來分隔單詞；用點來分隔描述性名字和型別，
具體來說，就是先描述組件特性，再描述它的型別的模式，并且對所有組件使用一致的型別命名規則！！！
也就是 feature.type.ts，例如 hero.service.ts, app.module.ts, home.component.html, global.style.css，
常常使用的后綴有 *.service、*.component、*.pipe、.module、.directive，如果有必要，可以創建更多型別名，但必須注意，不要創建太多了，
這樣命名檔案可以讓我們來快速的識別檔案中有什么，并且輕松的利用編輯器或者 IDE 的模糊搜索功能找到特定檔案型別，或是為自動化任務提供模式匹配，
檔案名與符號名
如果將將檔案命名為 hero.service.ts，那么符號名，即類/變數名，應該命名為 HeroService，
若為 todo-list.service.ts，則該命名為 TodoListService，
也就是說，使用大寫駝峰命名法來命名類，并且需要匹配符號名與它所在的檔案名，在符號名后面追加約定的型別后綴（例如 Component、Service），
單元測驗檔案名
應該與測驗的檔案保持一致，xxx.xx.ts 的單元測驗檔案名應該叫做 xxx.xx.spec.ts，
結構組織與 LIFT 原則
我們應該力求專案結構組織符合 LIFT 原則：
- Locate 快速定位代碼
- Identify 一眼識別代碼
- Flattest 盡量保持扁平結構
- Try Do Not Repeat Yourself 嘗試遵循不重復自己的原則
上述四項原則重要程度從大到小，
為何？
LIFT 提供了一致的結構，它具有擴展性強、模塊化的特性，它讓我們可以快速鎖定代碼，提高開發的效率，
另外，檢查應用結構是否合理的方法是問問自己：“我能快速打開與此特性有關的所有檔案并開始作業嗎？”
Locate（定位）
堅持直觀、簡單和快速地定位代碼，
要想高效的作業，就必須能迅速找到檔案，特別是當不知道（或不記得）檔案名時——把相關的檔案一起放在一個直觀的位置可以節省大量的時間，
并且富有描述性的目錄結構會讓你和后面的維護者眼前一亮！！！
可以使用上面說的，使用 特性 + 后綴 + 檔案型別 的命名方式來方便我們的定位
Identify（識別）
檔案的名字請達到這個程度：看到名字立刻知道它包含了什么，代表了什么，
檔案名要具有說明性，保證檔案名精準的方法就是：確保檔案中只包含一個組件，
避免創建包含多個組件、服務或者混合體的檔案，
為何？
花費更少的時間來查找和琢磨代碼，就會變得更有效率，較長的檔案名遠勝于較短卻容易混淆的縮寫名，
Flattest（扁平）
請堅持盡可能保持扁平的目錄結構，
考慮當同一目錄下達到 7 個或更多個檔案時創建子目錄，
考慮配置 IDE，以隱藏無關的檔案，例如生成出來的 .js 檔案和 .js.map 檔案等，
沒人想要在超過七層的目錄中查找檔案！！！
扁平的結構有利于搜索，
另一方面，心理學家們相信，當關注的事物超過 9 個時，人類就會開始感到吃力，所以，當一個檔案夾中的檔案有 10 個或更多個檔案時，可能就是創建子目錄的時候了，
還是根據你自己的舒適度而定吧，除非創建新檔案夾能有顯著的價值，否則盡量使用扁平結構，
Try Do Not Repeat Yourself (T-DRY)
堅持 DRY（Don't Repeat Yourself，不重復自己），
避免過度 DRY，以致犧牲了閱讀性，
雖然 DRY 很重要，但如果要以犧牲 LIFT 的其它原則為代價，那就不值得了，這也就是為什么它被稱為 「Try」-DRY，
推薦的目錄結構
堅持把所有源代碼都放到名為 src 的目錄里，
堅持如果組件具有多個伴生檔案 (.ts、.html、.css 和 .spec)，就為它創建一個檔案夾，
我習慣使用的前端目錄結構：
- src
- app
- moduleA // 模塊 B
- assets
- components
- ...
- moduleB // 模塊 A
- shared // 共享模塊
- layouts
- assets
- main.ts
- ...
（完）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/250114.html
標籤：其他
上一篇：微信小程式之高德地圖多點路線規劃