(參考angular官方文件中的風格指南,詳細資訊可在中檢視.)
編寫目的:
1.使用統一的編碼規範是使應用程式的結構和編碼風格標準化,以便於閱讀和理解這段編碼。
2.好的編碼約定可使**嚴謹,可讀性強且意義清楚,並且盡可能直觀。
適用範圍:
1.本文件主要為前端angular開發語言的規範,不適用於其他語言規範.
2.適用人員:所有開發人員。
具體編碼規範:
1. 單一職責:
堅持每個檔案只定義一樣東西(例如:模組,路由,元件,服務,基類等)。
2. 總體命名:
堅持所有符號使用一致的命名規則,遵循同乙個模式來描述符號的特性和型別,模式為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宣告變數，除非它們的值在應用的生命週期內會發生變化。(hero_routes)
介面: 堅持使用大寫駝峰命名法來命名介面。
屬性和方法: 堅持使用小寫駝峰命名法來命名屬性和方法。
避免為私有屬性和方法新增下劃線字首。(private _toastcount: number;)
匯入語句中的空行: 堅持在第三方匯入和應用匯入之間留乙個空行。
4. 應用程式結構與 angular 模組
所有應用程式的源**都放到名叫src的目錄裡。
所有特性區都在自己的資料夾中，帶有它們自己的 angular 模組。
所有內容都遵循每個檔案乙個特性的原則。每個元件、服務和管道都在自己的檔案裡。
所有第三方程式包儲存到其它目錄裡，而不是src目錄。
你不會修改它們，所以不希望它們弄亂我們的應用程式。
定位:堅持直觀、簡單和快速地定位**。
為何？ 要想高效的工作，就必須能迅速找到檔案，特別是當不知道（或不記得）檔名時。 把相關的檔案一起放在乙個直觀的位置可以節省時間。 富有描述性的目錄結構會讓你和後面的維護者眼前一亮。
識別:堅持命名檔案到這個程度：看到名字立刻知道它包含了什麼，代表了什麼。
堅持檔名要具有說明性，確保檔案中只包含乙個元件。
避免建立包含多個元件、服務或者混合體的檔案。
扁平: 堅持盡可能保持扁平的目錄結構。
考慮當同一目錄下達到 7 個或更多個檔案時建立子目錄
按特性組織的目錄結構: 堅持根據特性區命名目錄。
共享特性模組:
在shared目錄中建立名叫sharedmodule的特性模組
在共享模組中宣告那些可能被特性模組引用的可復用元件、指令和管道。
考慮把可能在整個應用中到處引用的模組命名為sharedmodule
避免在共享模組中提供服務。服務通常是單例的，應該在整個應用或乙個特定的特性模組中只有乙份。
堅持在sharedmodule中匯入所有模組都需要的資產（例如commonmodule和formsmodule）。
避免在sharedmodule中指定應用級的單例服務提供商。如果是刻意要得到多個服務單例也行，不過還是要小心。(惰性載入的特性模組如果匯入了這個共享模組，會建立乙份自己的服務副本，這可能會導致意料之外的後果。
為何？對於單例服務，你不希望每個模組都有自己的例項。 而如果sharedmodule提供了乙個服務，那就有可能發生這種情況。)
核心特性模組
考慮把那些數量龐大、輔助性的、只用一次的類收集到核心模組中，讓特性模組的結構更清晰簡明。
堅持把要共享給整個應用的單例服務放進coremodule中（例如exceptionservice和loggerservice）。
堅持匯入coremodule中的資產所需要的全部模組（例如commonmodule和formsmodule） 堅持把應用級、只用一次的元件收集到coremodule中。
防止多次匯入coremodule
堅持防範多次匯入coremodule，並通過新增守衛邏輯來盡快失敗(阻止)。
惰性載入的目錄
某些邊界清晰的應用特性或工作流可以做成惰性載入或按需載入的，而不用總是隨著應用啟動。
堅持把惰性載入特性下的內容放進惰性載入目錄中。
典型的惰性載入目錄包含路由元件及其子元件以及與它們有關的那些資產和模組。
永遠不要直接匯入惰性載入的目錄
避免讓兄弟模組和父模組直接匯入惰性載入特性中的模組。(還會出現跳過子路由的異常情況!!!)
5. 元件
元件選擇器命名:
堅持使用中線 (dashed) 命名法或烤串 (kebab) 命名法來命名元件中的元素選擇器。
把元件當做元素:
考慮給元件乙個元素選擇器，而不是屬性或類選擇器。
把模板和樣式提取到它們自己的檔案:
堅持當超過 3 行時，把模板和樣式提取到乙個單獨的檔案。
堅持把模板檔案命名為[component-name].component.html，其中，[component-name] 是元件名。
內聯輸入和輸出屬性裝飾器:
堅持把@input()或者@output()放到所裝飾的屬性的同一行。(易於識別)
避免為輸入和輸出屬性指定別名:
避免除非有重要目的，否則不要為輸入和輸出指定別名。(同乙個屬性有兩個名字（乙個對內乙個對外）很容易導致混淆。)
成員順序:
堅持把屬性成員放在前面，方法成員放在後面。
堅持先放公共成員，再放私有成員，並按照字母順序排列。
把邏輯放到服務裡:
堅持在元件中只包含與檢視相關的邏輯。所有其它邏輯都應該放到服務中。
堅持把可重用的邏輯放到服務中，保持元件簡單，聚焦於它們預期目的。(便於復用,測試,解除依賴)
6. 指令
使用指令來增強已有元素:
堅持當你需要有表現層邏輯，但沒有模板時，使用屬性型指令。
7. 服務
服務總是單例的:
堅持在同乙個注入器內，把服務當做單例使用。用它們來共享資料和功能。
提供乙個服務:
堅持將服務提供到共享範圍內的頂級元件的 angular
注入器。(當不同的兩個元件需要乙個服務的不同的例項時，上面的方法這就不理想了。在這種情況下，對於需要嶄新和單獨服務例項的元件，最好在元件級提供服務。)
使用 @injectable() 類裝飾器:
堅持當使用型別作為令牌來注入服務的依賴時，使用@injectable()類裝飾器，而非@inject()引數裝飾器。
8. 資料服務
通過服務與 web 伺服器通訊:
堅持把資料操作和與資料互動的邏輯重構到服務裡。
堅持讓資料服務來負責 xhr 呼叫、本地儲存、記憶體儲存或者其它資料操作。
元件的職責是為檢視展示或收集資訊。它不應該關心如何獲取資料，它只需要知道向誰請求資料。把如何獲取資料的邏輯移動到資料服務裡，簡化了元件，讓其聚焦於檢視。 資料管理的詳情，比如頭資訊、方法、快取、錯誤處理和重試邏輯，不是元件和其它的資料消費者應該關心的事情。
前端編碼規範
從一篇文章上 前端編碼規範 摘取了自己還沒形成習慣的點 好的規範寫法 html語法 1.用兩個空格來代表製表符 tab 這是唯一能保證在所有 環境下獲得一致展現的方法 2.對於屬性的定義，確保全部使用雙引號，絕不要使用單引號 3.不要在自閉合元素的尾部新增斜線 屬性順序 html屬性應當按照以下給出...
規範 前端編碼規範 注釋規範
頂部新增檔案申明資訊，包括檔案描述 原始作者，如果有更新，則需要新增更新內容 更新作者和更新時間。description 說明文字 author 張三 description 說明文字 author 張三 update 更新內容 by 李四 2013 04 13 18 32 無論是單行注釋還是多行注...
前端 前端編碼規範小記
定位 position left right top bottom z index 盒子模型 display float width height margin padding border border radius 排印 font color background line height tex...