来源：Angular中文网-风格指南
由于使用的技术有限，故只选取了其中的一部分内容。
###单一职责 ####单一规则
- 坚持每个文件只定义一样东西（例如服务或组件）。
- 考虑把文件大小限制在 400 行代码以内。
####小函数
- 坚持定义简单函数
- 考虑限制在 75 行之内。
###命名 ####总体命名原则
- 坚持所有符号使用一致的命名规则。
- 坚持遵循同一个模式来描述符号的特性和类型。推荐的模式为 feature.type.ts。
####使用点和横杠来分隔文件名
- 坚持在描述性名字中，用横杠来分隔单词。
- 坚持使用点来分隔描述性名字和类型。
- 坚持遵循先描述组件特性，再描述它的类型的模式，对所有组件使用一致的类型命名规则。推荐的模式为 feature.type.ts。
- 坚持使用惯用的后缀来描述类型，包括 .service、.component、*.pipe、.module、.directive。 必要时可以创建更多类型名，但必须注意，不要创建太多。
####符号名与文件名
- 坚持为所有东西使用一致的命名约定，以它们所代表的东西命名。
- 坚持使用大写驼峰命名法来命名类。符号名匹配它所在的文件名。
- 坚持在符号名后面追加约定的类型后缀（例如 Component、Directive、Module、Pipe、Service）。
- 坚持在符号名后面追加约定的类型后缀（例如 .component.ts、.directive.ts、.module.ts、.pipe.ts、.service.ts）。
- 坚持在文件名后面追加约定的类型后缀（例如 .component.ts、.directive.ts、.module.ts、.pipe.ts、.service.ts）。
####服务名
- 坚持使用一致的规则命名服务，以它们的特性来命名。
- 坚持为服务的类名加上 Service 后缀。 例如，获取数据或英雄列表的服务应该命名为 DataService 或 HeroService。 有些词汇显然就是服务，比如那些以“-er”后缀结尾的。比如把记日志的服务命名为 Logger 就比 LoggerService 更好些。需要在你的项目中决定这种特例是否可以接受。 但无论如何，都要尽量保持一致。
####组件选择器
- 坚持使用中线命名法（dashed-case）或叫烤串命名法（kebab-case）来命名组件的元素选择器。
###应用程序结构与 NgModule ####LIFT
- 坚持组织应用的结构，力求：快速定位 (Locate) 代码、一眼识别 (Identify) 代码、 尽量保持扁平结构 (Flattest) 和尝试 (Try) 遵循 DRY (Do Not Repeat Yourself, 不重复自己) 原则。
- 坚持四项基本原则定义文件结构，上面的原则是按重要顺序排列的。
####定位
- 坚持直观、简单和快速地定位代码。
####识别
- 坚持命名文件到这个程度：看到名字立刻知道它包含了什么，代表了什么。
- 坚持文件名要具有说明性，确保文件中只包含一个组件。
####扁平
- 坚持尽可能保持扁平的目录结构。
- 考虑当同一目录下达到 7 个或更多个文件时创建子目录。
- 考虑配置 IDE，以隐藏无关的文件，例如生成出来的 .js 文件和 .js.map 文件等。
####总体结构的指导原则
- 坚持从零开始，但要考虑应用程序接下来的路往哪儿走。
- 坚持有一个近期实施方案和一个长期的愿景。
- 坚持把所有源代码都放到名为 src 的目录里。
- 坚持如果组件具有多个伴生文件 (.ts、.html、.css 和 .spec)，就为它创建一个文件夹。