读 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
- ...
（完）