目录
- 介绍
- 代码规范检查与修复
- 在git commit时自动检查代码规范
- 后记
介绍
在团队协作开发中,代码规范是必要的。以前的规范都是自己定,然后手动检查,很难做到有效的约束。
现代的PHP,则有得到广泛认可的编码规范:PSR-1
,PSR-2
。
同时也有配套的包squizlabs/php_codesniffer
(下面简称phpcs)可以自动检查代码是否符合规范,并能自动修复部分不规范的代码。
结合brainmaestro/composer-git-hooks
,可以进一步做到,在git commit
时,强制代码规范的检查。
代码规范检查与修复
安装phpcs
包:
composer require squizlabs/php_codesniffer --dev
这个包,包含了2个工具:
- phpcs用于检查代码规范;
- phpcbf用于根据代码规范修复代码。
工具位于vendor/bin/
目录。
假设要检查app/
目录下的代码是否符合规范,执行:
$vendor/bin/phpcs --standard=PSR1,PSR2 app/ routes/ config/
其中,--standard
用于指定检查规范时使用的标准,这里使用PSR1和PSR2。而app/,routes/和config/是laravel工程的代码目录。
手动修复代码规范是一件很累人的事情,一般是先通过自动修复,对于修复不成功的再手动修复。执行以下命令可以完成自动修复。
$vendor/bin/phpcbf --standard=PSR1,PSR2 app/ routes/ config/
有些规则,phpcbf
无法自动修复,而我们改起来又十分烦琐,可以考虑自定义这些规则。比如上面截图中的一行不能超过120个字符的这条规则,无法被自动修复,但不论是第三方包,还是我们自己写的代码(通常是注释),超过120个字符的非常多,一一修复就太累了。于是修改了该条规则,将数值扩大到240。
具体方法是创建ruleset.xml文件,拷贝以下内容
<?xml version="1.0"?>
<ruleset name="Custom">
<description>Zend, but without linelength check.</description>
<rule ref="Generic.Files.LineLength">
<properties>
<property name="lineLimit" value="240"/>
<property name="absoluteLineLimit" value="0"/>
</properties>
</rule>
</ruleset>
然后在执行代码检查时,在--standard
参数附上自定义规则文件路径
$vendor/bin/phpcs --standard=PSR1,PSR2,./ruleset.xml app/ routes/ config/
每次要敲这么长的命令并不方便,一般是写在composer.json
中,通过composer lint
执行代码检查,通过composer lint-fix
修复代码。
要实现这样的效果,修改composer.json
, 在scripts增加:
"scripts": {
// 省略其他部分...
"lint": "phpcs --standard=PSR1,PSR2,./ruleset.xml app/ routes/ config/ ",
"lint-fix": "phpcbf --standard=PSR1,PSR2 app/ routes/ config/ "
}
然后执行composer lint
和composer lint-fix
试试。
在git commit时自动检查代码规范
在上一节中,我们已经支持代码规范检查和代码修复。但是实际开发中,常常会忘记要去检查。为了更好的管控流程,最好能在git commit时自动检查,如果不符合规范就停止commit。这就需要使用git的hooks机制,在pre-commit时,执行规范检查和代码修复 。可以直接编辑 .git/hooks/pre-commit
,写入在每次git commit之前要执行的脚本。
也可以通过brainmaestro/composer-git-hooks
这个包解决此问题,这里使用后面这个方案。
首先安装包:
$composer require brainmaestro/composer-git-hooks
然后编辑composer.json,在extra增加:
"extra": {
// 省略其他部分...
"hooks": {
"pre-commit": [
"echo committing as $(git config user.name)",
"composer run lint"
]
}
},
写好脚本以后还不能直接使用,需要先通过vendor/bin/cghooks
生成.git/hooks/pre-commit
。
$vendor/bin/cghooks add # 将创建.git/hooks/pre-commit
或者
$vendor/bin/cghooks update ## 将composer.json的内容更新到.git/hooks/pre-commit
如果composer.json与.git不是在同一个目录下,还需要加--git-dir参数,比如
vendor/bin/cghooks add --git-dir="../.git"
生成.git/hooks/pre-commit
以后,就可以试试,修改一些文件,然后执行git commit看看git hooks有没有被触发。类似下面的执行结果。然后如果有执行错误,会发现git commit
不成功。
至此,代码规范的检查就大功告成了。
后记
- 其实就是将
nodejs
的eslint
,husky
对应到php
版本(没有prettier
)。 - 有些工程,前端代码和后端代码放在同一个git工程下的不同目录,js那边使用husky自动生成
pre-commit
钩子,而laravel这边使用了brainmaestro/composer-git-hooks
钩子生成了pre-commit
,会出现相互覆盖的问题。解决此问题的方法是有2种:一种是创建一个scripts/pre-commit
,让开发者在clone
工程以后,拷贝到.git/hooks/pre-commit
;另一种就是在工程根目录下安装husky
,然后在将工程中所有commit
之前要做的检查都写入进来。推荐使用第2种方法,husky
这个包做得比php这边的包要好用。