读 Angular 代码风格指南

发布时间:2021-06-23 发布网站:前端之家 F2er.com
前端之家收集整理的这篇文章主要介绍了读 Angular 代码风格指南前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

原文地址: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

- ...

(完)

总结


以上是前端之家为你收集整理的读 Angular 代码风格指南全部内容,希望文章能够帮你解决读 Angular 代码风格指南所遇到的程序开发问题。

如果觉得前端之家网站内容还不错,欢迎将前端之家网站推荐给前端开发程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。