目录
- 工具简介
- 实现思路
- 具体实现
- 总结
- 附录
代码千万行,标准第一行。
编码不标准,共事两行泪。
早几年接手过一个我的项目,一堆bug不说,代码还又臭又长,据说之前写代码的那位仁兄常常改一个bug又带出十个bug我的项目里充斥着各种含意不明的变量、没有用到的不晓得从哪里复制粘贴过去的函数、乌七八糟的console、得心应手的空行和毫无意义的正文……
很多程序员没有代码标准意识,常常感觉只有性能能用就行了,代码标准浪费时间,于是写进去的代码过一段时间可能连本人都看不懂是坨什么货色,更不用说接手的共事了。
今日便来说说,如何从技术层面,实现代码标准以及代码提交标准。
1、工具简介
- husky:一个Git hooks工具,能够让咱们在git提交前后进行一些操作,比方,在提交之前查看代码是否标准、进行对立的格式化解决、查看git提交的信息格式等等;
- eslint:一个用NodeJS写的Javascript代码查看工具,可自定义规定;
- lint-staged:一个可能只对git变更文件进行代码查看的工具;
- commitizen:一个提供了交互式命令,可用于标准git commit信息的工具。
以上就是咱们这次要用到的四个工具。
2、实现思路
咱们能够通过husky提供的钩子(hooks):
- 在git提交前,应用eslint或者lint-staged对代码进行查看,并进行对立的格式化解决;
- 在git提交时,查看git commit的格局是否符合规定;同时,应用commitizen实现命令行交互,来辅助咱们生成合规的git commit。
3、具体实现
3.1 husky
装置:
yarn add husky -D
在package.json
的script
中增加:
"scripts": { "prepare": "husky install"}
prepare
是npm
的生命周期脚本。
当执行npm install
的时候,就会主动执行脚本内容husky install
,从而在以后我的项目的根目录下生成.husky
文件夹。
这里的husky.sh
配置次要是为了获取hook的执行后果,当执行过程中出错时,就退出过程。
接下来就能够欢快地应用git hooks啦。
3.2 hook:pre-commit
命令行执行yarn husky add .husky/pre-commit
生成pre-commit
脚本(当然也能够手动):
#!/bin/sh. "$(dirname "$0")/_/husky.sh"undefined
稍作批改,来验证下在git commit的时候是否执行了这个脚本:
#!/bin/sh. "$(dirname "$0")/_/husky.sh"echo "commit之前执行"
命令行git提交代码:
git add .git commit -m”add husky config”
能够看到pre-commit脚本执行胜利,打印出了语句。
3.3 在pre-commit里增加eslint查看
装置:
yarn add eslint —dev
装置实现后,执行
yarn run eslint —init
或
./node_modules/.bin/eslint —init
执行实现后会主动在根目录生成eslint
配置文件.eslinttrc.js
。
批改pre-commit
,增加eslint格局查看:
#!/bin/sh. "$(dirname "$0")/_/husky.sh"echo "eslint格局校验" && ./node_modules/.bin/eslint src/*
能够看到,eslint检测出代码里有2个error
和1个warning
。
error是必须批改的,能够应用eslint --fix
主动修复,并执行git add .
把fix后的变更也增加到git缓存区:
#!/bin/sh. "$(dirname "$0")/_/husky.sh"echo "eslint格局校验"./node_modules/.bin/eslint src/* --fix # 对src下的所有文件作eslint查看,并用--fix修复errorgit add . # 将eslint的fix内容也增加到git提交中
测试一下:
胜利!
提醒:如果应用的是Github Desktop这类的图形工具,有可能会呈现上面这个谬误——
这是因为咱们只在我的项目里装置了eslint,当在软件上运行的时候就有可能呈现门路谬误,只须要全局装置一下eslint就能够了:
yarn add eslint -g
下面的eslint查看脚本会对src
中的所有文件进行查看。如果是一个新我的项目还好,如果是一些老我的项目,那么波及到的变更文件就会很多。
如果不想每次都全量检测,那么能够通过git diff
来获取到变更的文件:
批改pre-commit:
#!/bin/sh. "$(dirname "$0")/_/husky.sh"echo "eslint格局校验"arr=`git diff --name-only HEAD` # 查看变更文件for filepath in ${arr[@]}do if [[ "$filepath" =~ ^[src/] ]]; then : # 只检测src下被批改的文件的格局 if [ -f "$filepath" ];then # 只对存在的文件进行fix,跳过delete的文件 echo $filepath ./node_modules/.bin/eslint $filepath --fix git add $filepath fi fidone
这段代码实现了:只对src中有变更且非删除的文件进行eslint检查和fix。
这里举荐一个工具,也就是下面提到的lint-staged,也能实现同样的性能,应用起来更简略。
执行npx mrm@2 lint-staged
,能够看到package.json
中多了对于lint-staged
的配置:
批改一下:
"lint-staged": { "src/*": "eslint --fix"}
pre-commit改为:
#!/bin/sh. "$(dirname "$0")/_/husky.sh"echo "eslint格局校验"npx lint-staged
测试一下:
胜利!
至此,咱们就实现了根本的代码标准配置。
eslint的具体配置参数这里就不开展了,感兴趣的同学能够去官网上自行摸索。
3.4 用commitizen标准git commit
装置:
npm install --save-dev commitizen
在package.json中配置:
"scripts": { "commit": "cz" }, "config": { "commitizen": { "path": "cz-conventional-changelog" } }
测试一下:
留神,这里就不能用git commit
了,而要用yarn run commit或npm run commit,执行后命令行里会呈现一些交互选项,来帮忙咱们生成git commit。
看不习惯英文的也能够装置中文包:
yarn add cz-conventional-changelog-zh
commitizen只能帮忙咱们生成标准的git commit,如果有些队友忘了应用yarn run commit,而间接用git commit -m”xxx”写了不标准的提交信息,怎么办?
还记得下面说的husky吗?咱们能够通过husky的commit-msg钩子来校验git commit的提交信息。
3.5 hook:commit-msg
yarn husky add .husky/commit-msg
批改commit-msg:
#!/bin/sh. "$(dirname "$0")/_/husky.sh"commit_regex='^Merge.+|(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types)(\(.+\))?: .{1,50}'if ! grep -iqE "$commit_regex" "$1"; thenechoecho "commit信息格式谬误!!"echo "格局应为:[Type]: [Summary]"echo "Type可选值为Merge|feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types"echo "留神两头的空格"echo "示例:git commit -m \"test: add something test\""echoexit 1fi
测试一下:
功败垂成!
4、总结
标准的代码不仅能缩小合并抵触,还有助于进步代码的可读性,升高之后的保护老本。
对团队而言,有可能是铁打的代码流水的程序员,前人留下的坑得前人去填,标准代码是十分必要的。
对集体而言,标准的代码不仅能缩小bug的呈现,还有助于更好地了解编程语言的个性,成长有时候就是这些细节处的积攒。
技术上只能起到一部分的标准作用,更重要的还是意识上的主观能动性,只有意识到代码标准的重要性,能力真正实现我的项目的代码规范化。
附录
- husky
- eslint
- lint-staged
- commitizen
- airbnb代码标准