原文出處：https://blog.csdn.net/fen747042796/article/details/78880424

本文為筆者對Angular官網風格指南的整理版本，刪除／增加了部分內容。另外，原文對每個規範都作出了原因的解釋，個別還有示例，需要的請點選檢視原文。

原連結：英文文件  ／  中文文件 （ 建議閱讀） 或 
延伸閱讀：Angular規範 （中文文件 相似）

單一職責

單一檔案

• 一個檔案定義一樣東西，比如一個元件、一個服務、一個管道、一個指令
• 每個檔案最多不要超過400行

單一函式

• 定義功能單一的函式
• 一個函式最多不要超過75行

命名規範

• 檔名採用feature.type.**，feature表示特性，type表示型別 

1. 模組用 .module.ts
2. 路由模組用 -routing.module.ts
3. 元件用 .component.ts|html|css
4. 服務用 .service.ts
5. 管道用 .pipe.ts
6. 指令用 .directive.ts
7. 型別用 .model.ts 
8. 資料用 .data.ts

• 用”-“來分割單詞，比如hero-list.component.ts
• 單元測試檔名保持和測試物件一致，並以.spec.ts結尾
• 端到端測試檔名保持和測試物件一致，並以.e2e-spec.ts結尾
• 類名用大寫駝峰規則，並且保持跟檔名的一致 

1. 模組：比如app.module.ts定義的類名為AppModule  
2. 路由模組：比如app-routing.module.ts定義的類名魏AppRoutingModule
3. 元件：比如hero-list.component.ts定義的類名為HeroListComponent
4. 服務：比如logger.service.ts定義的類名為LoggerService
5. 管道：比如address.pipe.ts定義的類名為AddressPipe
6. 指令：比如highlight.directive.ts定義的類名為HighlightDirective
7. 型別例外：按模組來劃分，一個.model.ts定義多個型別
8. 資料：比如address-book.data.ts定義的變數名為addressBook

• 指令碼啟動入口的檔名規定為main.ts，裡面不包括任何業務邏輯，但要記得處理失敗的情況

// main.ts
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';

platformBrowserDynamic().bootstrapModule(AppModule)  
    .then(success => console.log(`Bootstrap success`))  
    .catch(err => console.error(err));

• 指令選擇器的命名採用小寫駝峰規則，比如clickOutSide 
• 元件選擇器的命名採用分隔符“-”連線小寫字母的形式，比如hero-list

程式碼規範

• 類命名採用大寫駝峰規則
• 常量定義用const，並且全部大寫，如果有多個單詞，用“_”連線，比如HERO_URL
• 支援ES6的環境下，禁止使用var定義變數
• 變數命名儘量控制在3個單詞以內，有常見縮寫形式的單詞可採用縮寫形式
• 介面型別用大寫駝峰規則，不建議以I為字首，考慮用類代替介面
• 屬性和方法名用小寫駝峰，私有屬性和方法不建議以“_”為字首
• 建議用空一行的方式來區分第三方庫的匯入和專案本身檔案的匯入

專案結構

• 好的專案結構的準則就是快速定位，快速識別，儘可能保持扁平，不要寫冗餘／重複程式碼
• 把所有專案程式碼放入src資料夾，為每個特性建立資料夾
• 第三方庫放在src外的一個資料夾
• 每個元件、服務、管道、指令都獨成一個檔案
• 當元件有多個附屬檔案時（htm，css，ts，spec.ts），建議建立一個獨立的資料夾

模組

• 在src/app下建立根模組，建議命名為app.module.ts
• 為每個特性建立一個模組，並且保持資料夾命名和模組命名一致
• 共享模組建議用SharedModule命名，放在app/shared/shared.module.ts中
• 在共享模組中定義複用的元件、指令和管道，避免在共享模組中定義服務
• 在共享模組中匯入所有必需的模組，比如CommonModule和FormsModule，匯出所有複用的模組、元件、指令、管道
• 考慮將只用一次的類放在核心特性模組中，並且僅在根模組中匯入，建議寫guard.ts來保證
• 核心特性模組建議用CoreModule命名，放在app/core/core.module.ts中
• 將單例服務放在核心特性模組中，比如ExceptionService和LoggerService
• 在核心特性模組中匯入所有必需的模組，比如CommonModule和FormsModule，匯出所有定義的元件，服務等
• 將全域性僅用一次的元件放在核心特性模組，然後只在AppModule中匯入，比如NavComponent和SpinnerComponent
• 獨立的特性模組可以做成懶載入模組，避免在任何地方匯入懶載入模組，不然模組就會直接載入

元件

• 當模板／樣式超過3行時，寫成單獨檔案
• 刪除無樣式定義的樣式檔案
• 模板／樣式的定義與元件命名保持一致
• 匯入時使用相對路徑
• 用裝飾器@Input和@Output來修改輸入輸出資料，而不是使用元資料中的inputs和outputs屬性
• 不推薦重新命名輸入輸出資料
• 按照變數，構造器，生命週期函式，一般方法的順序定義；一般方法按頁面的功能模組放一起，被呼叫的方法寫在後面；變數和方法均先公有後私有排列；
• 元件中只寫跟檢視相關的邏輯，把其他的業務邏輯放在服務中
• 將可複用的業務邏輯放在服務中
• 不推薦事件命名加上on字首
• 將展示邏輯放在元件的類中，而不是在模板中

指令

• 當有跟模板無關的展示邏輯時，使用屬性指令，比如[highlight]指令
• 推薦使用@HostListener和@HostBinding，而不是元資料的host屬性

服務

• 保持單例服務的使用規則，服務用來在特性模組或者應用中共享資料和方法
• 跟函式一樣，一個服務只有一個目的
• 把服務注入在最高層的元件／模組中，使得該單例服務能在子元件、子模組中共享
• 使用@Injectable裝飾服務類，而不是@Inject裝飾引數 
• 跟資料相關的操作，比如xhr請求，本地儲存等抽象成服務

生命週期

• 需要生命週期鉤子時，實現相關的介面，可有效防止錯誤

輔助工具

• 用codelyzer來保持程式碼遵守該指南，當然你可以根據自己情況調整
• 使用IDE的程式碼片段工具來快速生成具有一致性的程式碼片段，比如給VS Code安裝snippets