(參考Angular官方文檔中的風(fēng)格指南,詳細(xì)信息可在https://angular.cn/guide/styleguide中查看.)

編寫目的:

1.使用統(tǒng)一的編碼規(guī)范是使應(yīng)用程序的結(jié)構(gòu)和編碼風(fēng)格標(biāo)準(zhǔn)化,以便于閱讀和理解這段編碼。

2.好的編碼約定可使代碼嚴(yán)謹(jǐn),可讀性強且意義清楚,并且盡可能直觀。

適用范圍:

1.本文檔主要為前端Angular開發(fā)語言的規(guī)范,不適用于其他語言規(guī)范.

2.適用人員:所有開發(fā)人員。

具體編碼規(guī)范:

1. 單一職責(zé):

堅持每個文件只定義一樣?xùn)|西(例如:模塊,路由,組件,服務(wù),基類等)。

2. 總體命名:

堅持所有符號使用一致的命名規(guī)則,遵循同一個模式來描述符號的特性和類型,模式為feature.type.ts.

使用點和橫杠來分割文件名(用’-’來分割單詞,用’.’來分割類型,例如:index-routing.module.ts) 。

堅持在符號名后面追加約定的類型后綴（例如.component.ts、.directive.ts、.module.ts、.pipe.ts、.service.ts）。

指令選擇器:
堅持使用小駝峰命名法來命名指令的選擇器(防止與html名字沖突,指令更加容易被識別)。

管道名:
堅持為所有管道使用一致的命名約定，用它們的特性來命名。

Angular NgModule 命名:
堅持為文件名添加.module.ts擴展名。

堅持為 RoutingModule 類名添加RoutingModule后綴。

堅持為 RoutingModule 的文件名添加-routing.module.ts后綴。

3. 編程約定:

堅持一致的編程、命名和空格的約定。

類:
堅持使用大寫駝峰命名法來命名類。

常量:
堅持用const聲明變量，除非它們的值在應(yīng)用的生命周期內(nèi)會發(fā)生變化。(HERO_ROUTES)

接口:
堅持使用大寫駝峰命名法來命名接口。

屬性和方法:
堅持使用小寫駝峰命名法來命名屬性和方法。

避免為私有屬性和方法添加下劃線前綴。(private _toastCount: number;)

導(dǎo)入語句中的空行:
堅持在第三方導(dǎo)入和應(yīng)用導(dǎo)入之間留一個空行。

4. 應(yīng)用程序結(jié)構(gòu)與 Angular 模塊

所有應(yīng)用程序的源代碼都放到名叫src的目錄里。

所有特性區(qū)都在自己的文件夾中，帶有它們自己的 Angular 模塊。

所有內(nèi)容都遵循每個文件一個特性的原則。每個組件、服務(wù)和管道都在自己的文件里。

所有第三方程序包保存到其它目錄里，而不是src目錄。

你不會修改它們，所以不希望它們弄亂我們的應(yīng)用程序。

定位:

堅持直觀、簡單和快速地定位代碼。

為何？ 要想高效的工作，就必須能迅速找到文件，特別是當(dāng)不知道（或不記得）文件名時。 把相關(guān)的文件一起放在一個直觀的位置可以節(jié)省時間。 富有描述性的目錄結(jié)構(gòu)會讓你和后面的維護者眼前一亮。

識別:

堅持命名文件到這個程度：看到名字立刻知道它包含了什么，代表了什么。

堅持文件名要具有說明性，確保文件中只包含一個組件。

避免創(chuàng)建包含多個組件、服務(wù)或者混合體的文件。

扁平:
堅持盡可能保持扁平的目錄結(jié)構(gòu)。

考慮當(dāng)同一目錄下達(dá)到 7 個或更多個文件時創(chuàng)建子目錄

按特性組織的目錄結(jié)構(gòu):
堅持根據(jù)特性區(qū)命名目錄。

共享特性模塊:

在shared目錄中創(chuàng)建名叫SharedModule的特性模塊

在共享模塊中聲明那些可能被特性模塊引用的可復(fù)用組件、指令和管道。

考慮把可能在整個應(yīng)用中到處引用的模塊命名為SharedModule

避免在共享模塊中提供服務(wù)。服務(wù)通常是單例的，應(yīng)該在整個應(yīng)用或一個特定的特性模塊中只有一份。

堅持在SharedModule中導(dǎo)入所有模塊都需要的資產(chǎn)（例如CommonModule和FormsModule）。

避免在SharedModule中指定應(yīng)用級的單例服務(wù)提供商。如果是刻意要得到多個服務(wù)單例也行，不過還是要小心。(惰性加載的特性模塊如果導(dǎo)入了這個共享模塊，會創(chuàng)建一份自己的服務(wù)副本，這可能會導(dǎo)致意料之外的后果。

為何？對于單例服務(wù)，你不希望每個模塊都有自己的實例。 而如果SharedModule提供了一個服務(wù)，那就有可能發(fā)生這種情況。)

核心特性模塊

考慮把那些數(shù)量龐大、輔助性的、只用一次的類收集到核心模塊中，讓特性模塊的結(jié)構(gòu)更清晰簡明。

堅持把那些“只用一次”的類收集到CoreModule中，并對外隱藏它們的實現(xiàn)細(xì)節(jié)。簡化的AppModule會導(dǎo)入CoreModule，并且把它作為整個應(yīng)用的總指揮。

堅持在core目錄下創(chuàng)建一個名叫CoreModule的特性模塊（例如在app/core/core.module.ts中定義CoreModule）。

堅持把要共享給整個應(yīng)用的單例服務(wù)放進(jìn)CoreModule中（例如ExceptionService和LoggerService）。

堅持導(dǎo)入CoreModule中的資產(chǎn)所需要的全部模塊（例如CommonModule和FormsModule）
堅持把應(yīng)用級、只用一次的組件收集到CoreModule中。

只在應(yīng)用啟動時從AppModule中導(dǎo)入它一次，以后再也不要導(dǎo)入它（例如NavComponent和SpinnerComponent）。

避免在AppModule之外的任何地方導(dǎo)入CoreModule。

堅持從CoreModule中導(dǎo)出AppModule需導(dǎo)入的所有符號，使它們在所有特性模塊中可用。

防止多次導(dǎo)入CoreModule

應(yīng)該只有AppModule才允許導(dǎo)入CoreModule。

堅持防范多次導(dǎo)入CoreModule，并通過添加守衛(wèi)邏輯來盡快失敗(阻止)。

惰性加載的目錄

某些邊界清晰的應(yīng)用特性或工作流可以做成惰性加載或按需加載的，而不用總是隨著應(yīng)用啟動。

堅持把惰性加載特性下的內(nèi)容放進(jìn)惰性加載目錄中。

典型的惰性加載目錄包含路由組件及其子組件以及與它們有關(guān)的那些資產(chǎn)和模塊。

永遠(yuǎn)不要直接導(dǎo)入惰性加載的目錄

避免讓兄弟模塊和父模塊直接導(dǎo)入惰性加載特性中的模塊。(還會出現(xiàn)跳過子路由的異常情況!!!)

5. 組件

組件選擇器命名:

堅持使用中線 (dashed) 命名法或烤串 (kebab) 命名法來命名組件中的元素選擇器。

把組件當(dāng)做元素:

考慮給組件一個元素選擇器，而不是屬性或類選擇器。

把模板和樣式提取到它們自己的文件:

堅持當(dāng)超過 3 行時，把模板和樣式提取到一個單獨的文件。

堅持把模板文件命名為[component-name].component.html，其中，[component-name] 是組件名。

內(nèi)聯(lián)輸入和輸出屬性裝飾器:

堅持把@Input()或者@Output()放到所裝飾的屬性的同一行。(易于識別)

避免為輸入和輸出屬性指定別名:

避免除非有重要目的，否則不要為輸入和輸出指定別名。(同一個屬性有兩個名字（一個對內(nèi)一個對外）很容易導(dǎo)致混淆。)

成員順序:

堅持把屬性成員放在前面，方法成員放在后面。

堅持先放公共成員，再放私有成員，并按照字母順序排列。

把邏輯放到服務(wù)里:

堅持在組件中只包含與視圖相關(guān)的邏輯。所有其它邏輯都應(yīng)該放到服務(wù)中。

堅持把可重用的邏輯放到服務(wù)中，保持組件簡單，聚焦于它們預(yù)期目的。(便于復(fù)用,測試,解除依賴)

6. 指令

使用指令來增強已有元素:

堅持當(dāng)你需要有表現(xiàn)層邏輯，但沒有模板時，使用屬性型指令。

7. 服務(wù)

服務(wù)總是單例的:

堅持在同一個注入器內(nèi)，把服務(wù)當(dāng)做單例使用。用它們來共享數(shù)據(jù)和功能。

提供一個服務(wù):

堅持將服務(wù)提供到共享范圍內(nèi)的頂級組件的 Angular

注入器。(當(dāng)不同的兩個組件需要一個服務(wù)的不同的實例時，上面的方法這就不理想了。在這種情況下，對于需要嶄新和單獨服務(wù)實例的組件，最好在組件級提供服務(wù)。)

使用 @Injectable() 類裝飾器:

堅持當(dāng)使用類型作為令牌來注入服務(wù)的依賴時，使用@Injectable()類裝飾器，而非@Inject()參數(shù)裝飾器。

8. 數(shù)據(jù)服務(wù)

通過服務(wù)與 Web 服務(wù)器通訊:

堅持把數(shù)據(jù)操作和與數(shù)據(jù)交互的邏輯重構(gòu)到服務(wù)里。

堅持讓數(shù)據(jù)服務(wù)來負(fù)責(zé) XHR 調(diào)用、本地儲存、內(nèi)存儲存或者其它數(shù)據(jù)操作。

組件的職責(zé)是為視圖展示或收集信息。它不應(yīng)該關(guān)心如何獲取數(shù)據(jù)，它只需要知道向誰請求數(shù)據(jù)。把如何獲取數(shù)據(jù)的邏輯移動到數(shù)據(jù)服務(wù)里，簡化了組件，讓其聚焦于視圖。
數(shù)據(jù)管理的詳情，比如頭信息、方法、緩存、錯誤處理和重試邏輯，不是組件和其它的數(shù)據(jù)消費者應(yīng)該關(guān)心的事情。