如何利用工具提升前端代码规范

代码不规范带来的问题很多,潜在风险一堆,读写起来都很辛苦,大多时候,也容易拆东墙补西墙,总之维护性极低。

最近从事的前端项目就存在这样情况,怎么解决呢,重构!当然这篇文章不是讲怎么重构的,话题太大了,这里讲下,我们是怎么通过一些工具去提升代码规范的。

有这样一个段子,就是看代码就能看出是项目由几个人在开发,这不是说明大家的风格不一致吗?我们都知道,好的Team,有好的规范,理论上出来的代码就应该像一个人写的一样。

好了,废话到此结束,开讲!

为了提升代码规范,我们遵从主流,用以下几个工具来搞!
editorconfig 、tslint、prettier、huskyrc

EditorConfig

EditorConfig帮助开发者定义和维护不同编辑器和IDE之间,代码风格的一致性,Team中大家的IDE,操作系统可能会存在差异,这样就会造成潜在的问题,利用这个插件可以形成一致化。

比如缩进风格,缩进空格数都可以明确指定,一般前端为2,后端为4
贴出我使用的配置,仅供参考

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# EditorConfig helps developers define and maintain consistent
# coding styles between different editors and IDEs
# editorconfig.org

root = true

[*]

# Change these settings to your own preference
indent_style = space
indent_size = 4

# We recommend you to keep these unchanged
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

[*.{css, scss, less, js, jsx, json, ts, tsx, sass, php, html, hbs, mustache, phtml, html.twig}]
indent_size = 2

使用

  1. IDE中EditorConfig插件安装
  2. 项目根路径下,添加配置文件.editorconfig,配置如上

TSLint

TSLint是TypeScipt代码静态分析工具,它负责检查代码的易读性,可维护性,函数错误。这里因为我们的项目在向TS迁移,所以使用了TSlint,对于JS项目,一般使用ESLint。

tslint中,我们配置一些rule,当程序文件违反了这些rule的时候,IDE中就会显示错误提醒(图1),并且在编译终端也会有错误提醒(图2)。这样开发者在开发代码时能够确保遵从一套开发规范。

说明

关于TSLint的配置项中有jsRules和rules两项,rule中规则适用于ts和tsx,jsRule会copy来自rule的规则,这些规则适用于js和jsx后缀文件,当然也可以在jsRule中重写规则。对于我当前的JS向TS项目转换再合适不过了,我可以利用lint也cover了js,jsx。

使用

  1. yarn add tslint
  2. 项目根路径下,添加配置文件tslint.json

假如lint未起作用,可以在lint文件打开情况下,单击右键,选择Apply TSLint Code Style Rules

Prettier

Prettier是一款代码格式化工具,看到这里可能会差异,与eslint有什么不同呢?的确,我也困惑过。但是冷静下来,品品定位

Prettier is an opinionated code formatter.

TSLint is an extensible static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors.

读读还是能看到差距的,一个侧重格式代码,一个侧重语法检查

贴出一套我使用的配置,仅供参考

1
2
3
4
5
6
7
8
9
10
11
12
# Prettier configuration

printWidth: 140
singleQuote: true
tabWidth: 2
useTabs: false

# js and ts rules:
arrowParens: avoid

# jsx and tsx rules:
jsxBracketSameLine: false

使用

  1. IDE安装Prettier插件
  2. yarn add prettier --dev
  3. 项目根路径下,添加配置文件.prettierrc.yaml配置文件,如上

可能的疑问

  1. prettier插件和node prettier包什么关系?IDE插件可以直接帮你去快速修复这些代码格式,而Node包安装可以赋予你命令执行格式化代码。假如插件Team成员没安装,怎么办,下面将会用到这个包
  2. 在coding时,比如我们写了句导入声明,使用的双引号,编辑器会提示我们程序有错,当我们执行格式化快捷键,会自动变成单引号,那这个修复是prettier的功劳还是lint呢?是lint,IDE安装prettier插件后,对于利用prettier格式化code是有专门的快捷键的,并不是我们常用的那个快捷键,IDE apply lint后,我们的格式化其实加上了自动修复功能,而这个本身相当于执行了lint –fix.对此,可以尝试prettier中设定单引号,lint双引号,然后格式化程序试试即可。
  3. 我在使用jhipster创建的项目发现prettier配置文件不起作用,发现文件后缀改成yaml,生效了,可能是IDE对于后缀支持有点问题,so 建议还是yaml吧。

Husky+lint-staged

有了上面几个神兵利器,总该了可以了吧,不行!还是会有事,比如代码单双引号,lint会帮我们检测,但是只是报错啊,如果开发者没注意还是提交了呢?CI走构建,lint阶段报错,这不是很尴尬吗?假如开发者没跑测试就提交,CI上跑半天到测试阶段过了,这也很尴尬,怎么办,怎么办,Husky就派上用途了。
GitHub上介绍如下

1
2
3
Git hooks made easy

Husky can prevent bad git commit, git push and more 🐶 woof!

也就是Husky可以实现在git commit,或者push触发前后执行特定的动作,这样就给我们提供了很好的机制来解决比如刚才代码不规范的这种情况了。

如下为我项目中的一个配置

1
2
3
4
5
6
{
"hooks": {
"pre-commit": "lint-staged",
"pre-push": "yarn run test"
}
}

这个意思是在提交前阶段执行lint-staged.在推送上游前执行test,假如我pre-commit执行命令改成yarn run test,也是可以的,那就意味着提交前,跑全部测试。不过这里我不打算改成那样,继续看下去。

lint-staged,这是个什么东西呢?假如不用这个东西,我们想在提交前prettier格式化代码,可能会是这样

1
2
3
4
5
{
"hooks": {
"pre-commit": "npm run prettier:format",
}
}

这样做,可以吗?可以!好吗?不好,因为一旦这样做,假如程序里面很多处都是不规范的代码,那么这样一次格式化就动的太多了,那么可能程序文件在这次提交后,假如去看annotate,到处都是你一个人,对于程序去追溯历史,并不好。怎么办呢,这个时候lint-staged就可以解决这个痛点

lint-staged的官方介绍是— Run linters on git staged files。它只会执行lint在staged的git文件,比如你只改动了A文件,那么执行的lint语法纠错或者格式化prettier只会对A文件起作用,这样最小化的改动岂不更好。这就是它的作用。

假如执行lint-staged,package.json文件中需要有对应的配置, 贴出我的配置

1
2
3
4
5
6
7
8
9
10
11
"lint-staged": {
"{,src/**/}*.{ts,tsx,js,jsx}": [
"tslint --fix",
"prettier --write",
"git add"
],
"{,src/**/}*.{md,json,css,scss}": [
"prettier --write",
"git add"
]
},

使用

1.yarn add husky --dev

  1. 项目根路径下,添加配置文件.huskyrc配置文件,如上

写在最后

似乎,工具还是挺多的,但是呢,一次投资,之后更多的是因地制宜,些许修改即可。有了EditorConfig控制你的IDE,TSLint控制code语法习惯,Prettier控制Code格式,Husky来确保提交代码执行了测试或者Lint,那么最终仓库的代码将是规范整洁的,那么程序质量至少在这个环节得到了明确的保障,我们就可以花更多的精力去从事业务的梳理及开发了。

所谓工欲善其事必先利其器,前端代码规范的工具链,值得重视及执行。希望能帮到道友,欢迎交流!

相关文档

Donate comment here