Automated checking of PHP code at commit
At one time, working in a narrow circle of programmers, individual tasks, and even projects, we did not think about the problems associated with staff turnover. To think more precisely, they thought, but they didn’t take any measures, and on the whole, no one left a united team and nobody “left”. With the growth of internal projects and corporate clients, the staff began to grow and it seemed that everything was fine - we were more, then we would have time to do more, but it was not there. We started to spend a lot of time on “useless” discussions, checks, excessive design, etc. The most annoying thing is the verification of the code. And then I began to think that “the wise and the ancients” probably solved these problems with hundreds, thousands of programmers, can we not cope? I decided to conduct an experiment called “automated verification of code style under commit”. For most of you, this is not news, and for sure you are using it, but I think it would not be superfluous to share the implementation experience.
At this early time, sitting at work and having a break for tea, I thought about it, tomorrow I need to go to the office and spend 2 to 3 hours again in the morning to check the code, then another 2 hours to set tasks, totaling 5 hours, then maybe work 2 hours and go home. And it’s clear that I’m not able to solve the tasks that have been set for the remaining 2 to 3 hours, and solving these problems at an inopportune time I can destroy my family, etc. So it can not continue. First of all, I am a programmer, not a “Cerberus” and I need to automate the verification process, if it doesn’t remove all the verification time, it will at least shorten it.
I don’t like to reinvent the wheel, so I immediately turned to the search engine and asked: “checking coding standards PHP”, looking at the first ten results, drew attention to the often found name “ PHP_Codesniffer ” and asking the same request — I saw that it was a PEAR library for automated code style checking , as they say - “what the doctor prescribed!” and the reliability of the developers, no doubt, which will have a beneficial effect in a possible global implementation. Installing the library on the server:
It is assumed that you have installed the PEAR distribution on the server. After installation, the new phpcs service will be available:
Having played a lot, I was pleased that this solution already supports many standards: Squiz, MySource, PHPCS, Zend, PEAR. It suited me, as we approved in due time that we will code according to the Zend standard.
For sharpening this library can be read in the official documentation.
')
Inspired by his discovery and its rapid “elevation”, the dream receded. The first problem was solved, now it remains to connect this solution to version control during a commit. The PHP_CodeSniffer documentation has a section dedicated to the description of integration with SVN - it was good, because we like to use SVN, but I use GIT and decided to write my own hook for git and then I think: “I don’t believe that PEAR doesn’t have an integration description with git. ” And again, turning to the search engine I found a ready solution phpcs-pre-commit :
To integrate this hook, you need to put the pre-commit file in the hooks folder of your git repository (.git / hooks). Who was interested in git hooks is the one in the subject.
And the last check of the commit I got a table with a description of the errors of not following the style. I will not give an example of how the phpcs error table displays, and why. In .git / hooks / pre-commit you need to specify which style you want to use:
Also indicate the file extensions you want to check:
If you get an error when commiting:
This means that the path to bash is not correct, change it in .git / hooks / pre-commit
The task as a whole is solved, plus CodeSniffer is that with it the obligation to check the “youthful” errors that are common to all disappears. And the main plus that will force the “young” to look at the code at least when looking for style errors and possibly conducting minimal refactoring.
Now you can go to work on Monday and talk about innovations. If this helps us, then it will be possible to lobby for the integration of this solution for all.
In general, everything was fine, but the project on which I decided to test, still quite ancient and to bring the Zend standard to some standard points, for example, camel style of variables. And I had to create my own standard for PHP_Codesniffer. The descriptions of the style check themselves lie in:
PEAR_PATH is the path to the folder with the PEAR libraries on our server, they are located in / usr / local / share / pear /.
To create your own style, create a folder YOUR_STYLE in PEAR_PATH / PHP / CodeSniffer / Standards /.
In the package of your style you need to create a ruleset.xml. About the format of this file, you can read here , I will describe only something that came in handy to me.
Due to the fact that the coding requirements are as close as possible to the Zend style, I simply copied the content from PEAR_PATH / PHP / CodeSniffer / Standards / Zend / ruleset.xml:
In the ruleset tag, replace the name with your name YOUR_STYLE and add one rule with Zend:
To disable the camel style I copy:
PEAR_PATH / PHP / CodeSniffer / Standards / Zend / Sniffs / NamingConventions / ValidVariableNameSniff.php in PEAR_PATH / PHP / CodeSniffer / Standards / YOUR_STYLE / Sniffs / NamingConventions / ValidVariableNameSniff.php. Renaming the class from Zend_Sniffs_NamingConventions_ValidVariableNameSniff to YOUR_STYLE_Sniffs_NamingConventions_ValidVariableNameSniff, added:
And he added everywhere a check for this “checkbox”. Now, if you need to override it, it can be done from ruleset.xml:
There were many moments on which the eyes were closed, but it was time to put them in order! The most useful code style check turned out to be a check for the length of a code line, and thanks to it a lot of unreadable places were fixed.
True, we encountered a problem with Russian comments, the entire code is stored in UTF-8, and CodeSniffer checks the length of the string with standard strlen and it’s logical that the lines doubled. I did not bother to redefine the class, which would be more correct, but simply in PEAR_PATH / PHP / CodeSniffer / Standards / Generic / Sniffs / Files / LineLengthSniff.php added:
and replaced strlen, with:
Hard week has passed with CodeSniffer, and here are some advantages:
Minuses:
Sunday, 3:40
At this early time, sitting at work and having a break for tea, I thought about it, tomorrow I need to go to the office and spend 2 to 3 hours again in the morning to check the code, then another 2 hours to set tasks, totaling 5 hours, then maybe work 2 hours and go home. And it’s clear that I’m not able to solve the tasks that have been set for the remaining 2 to 3 hours, and solving these problems at an inopportune time I can destroy my family, etc. So it can not continue. First of all, I am a programmer, not a “Cerberus” and I need to automate the verification process, if it doesn’t remove all the verification time, it will at least shorten it.
I don’t like to reinvent the wheel, so I immediately turned to the search engine and asked: “checking coding standards PHP”, looking at the first ten results, drew attention to the often found name “ PHP_Codesniffer ” and asking the same request — I saw that it was a PEAR library for automated code style checking , as they say - “what the doctor prescribed!” and the reliability of the developers, no doubt, which will have a beneficial effect in a possible global implementation. Installing the library on the server:
pear install PHP_CodeSniffer-1.3.0RC1It is assumed that you have installed the PEAR distribution on the server. After installation, the new phpcs service will be available:
phpcs --standard=Zend your.phpHaving played a lot, I was pleased that this solution already supports many standards: Squiz, MySource, PHPCS, Zend, PEAR. It suited me, as we approved in due time that we will code according to the Zend standard.
For sharpening this library can be read in the official documentation.
')
Sunday, 4:00
Inspired by his discovery and its rapid “elevation”, the dream receded. The first problem was solved, now it remains to connect this solution to version control during a commit. The PHP_CodeSniffer documentation has a section dedicated to the description of integration with SVN - it was good, because we like to use SVN, but I use GIT and decided to write my own hook for git and then I think: “I don’t believe that PEAR doesn’t have an integration description with git. ” And again, turning to the search engine I found a ready solution phpcs-pre-commit :
git clone https://github.com/s0enke/git-hooks.gitTo integrate this hook, you need to put the pre-commit file in the hooks folder of your git repository (.git / hooks). Who was interested in git hooks is the one in the subject.
And the last check of the commit I got a table with a description of the errors of not following the style. I will not give an example of how the phpcs error table displays, and why. In .git / hooks / pre-commit you need to specify which style you want to use:
PHPCS_CODING_STANDARD=ZendAlso indicate the file extensions you want to check:
PHPCS_FILE_PATTERN="\.(php|phtml)$"If you get an error when commiting:
error: cannot run .git/hooks/pre-commit: No such file or directoryThis means that the path to bash is not correct, change it in .git / hooks / pre-commit
The task as a whole is solved, plus CodeSniffer is that with it the obligation to check the “youthful” errors that are common to all disappears. And the main plus that will force the “young” to look at the code at least when looking for style errors and possibly conducting minimal refactoring.
Now you can go to work on Monday and talk about innovations. If this helps us, then it will be possible to lobby for the integration of this solution for all.
Monday 5:00 pm
In general, everything was fine, but the project on which I decided to test, still quite ancient and to bring the Zend standard to some standard points, for example, camel style of variables. And I had to create my own standard for PHP_Codesniffer. The descriptions of the style check themselves lie in:
PEAR_PATH/PHP/CodeSniffer/Standards/PEAR_PATH is the path to the folder with the PEAR libraries on our server, they are located in / usr / local / share / pear /.
To create your own style, create a folder YOUR_STYLE in PEAR_PATH / PHP / CodeSniffer / Standards /.
In the package of your style you need to create a ruleset.xml. About the format of this file, you can read here , I will describe only something that came in handy to me.
Due to the fact that the coding requirements are as close as possible to the Zend style, I simply copied the content from PEAR_PATH / PHP / CodeSniffer / Standards / Zend / ruleset.xml:
<?xml version= "1.0" ?>
<ruleset name= "Zend" >
<description>A coding standard based on an early Zend Framework coding standard. Note that this standard is out of date.</description>
<!-- Include some sniffs from all around the place -->
<rule ref = "Generic.Functions.FunctionCallArgumentSpacing" />
<rule ref = "Generic.Functions.OpeningFunctionBraceBsdAllman" />
<rule ref = "Generic.PHP.DisallowShortOpenTag" />
<rule ref = "Generic.WhiteSpace.DisallowTabIndent" />
<rule ref = "PEAR.Classes.ClassDeclaration" />
<rule ref = "PEAR.ControlStructures.ControlSignature" />
<rule ref = "PEAR.Functions.FunctionCallSignature" />
<rule ref = "PEAR.Functions.ValidDefaultValue" />
<rule ref = "PEAR.WhiteSpace.ScopeClosingBrace" />
<rule ref = "Squiz.Functions.GlobalFunction" />
<!-- Lines can be 80 chars long , show errors at 120 chars -->
<rule ref = "Generic.Files.LineLength" >
<properties>
<property name= "lineLimit" value = "120" />
<property name= "absoluteLineLimit" value = "140" />
</properties>
</rule>
<!-- Use Unix newlines -->
<rule ref = "Generic.Files.LineEndings" >
<properties>
<property name= "eolChar" value = "\n" />
</properties>
</rule>
</ruleset>
In the ruleset tag, replace the name with your name YOUR_STYLE and add one rule with Zend:
<rule ref = "Zend.Debug.CodeAnalyzer" />
To disable the camel style I copy:
PEAR_PATH / PHP / CodeSniffer / Standards / Zend / Sniffs / NamingConventions / ValidVariableNameSniff.php in PEAR_PATH / PHP / CodeSniffer / Standards / YOUR_STYLE / Sniffs / NamingConventions / ValidVariableNameSniff.php. Renaming the class from Zend_Sniffs_NamingConventions_ValidVariableNameSniff to YOUR_STYLE_Sniffs_NamingConventions_ValidVariableNameSniff, added:
public $isCheckCamelCaps;
And he added everywhere a check for this “checkbox”. Now, if you need to override it, it can be done from ruleset.xml:
<rule ref = "YOUR_STYLE.NamingConventions.ValidVariableName" >
<properties>
<property name= "isCheckCamelCaps" value = "1" />
</properties>
</rule>
Tuesday 19:00
There were many moments on which the eyes were closed, but it was time to put them in order! The most useful code style check turned out to be a check for the length of a code line, and thanks to it a lot of unreadable places were fixed.
True, we encountered a problem with Russian comments, the entire code is stored in UTF-8, and CodeSniffer checks the length of the string with standard strlen and it’s logical that the lines doubled. I did not bother to redefine the class, which would be more correct, but simply in PEAR_PATH / PHP / CodeSniffer / Standards / Generic / Sniffs / Files / LineLengthSniff.php added:
public $charset = 'UTF-8' ;
and replaced strlen, with:
mb_strlen($lineContent, $ this ->charset)
Saturday
Hard week has passed with CodeSniffer, and here are some advantages:
- Removed time and nerves to check the style of the code;
- when correcting errors for the length of lines, you revise the logic of the code, which has a beneficial effect on the readability of the code and refactoring of muddy logic. It also removes the need to explain when single-line if is good and when it is bad;
- no obligation to follow coding style documentation;
- Supports verification of all popular coding standards.
Minuses:
- It is inconvenient to introduce into “historical” projects or others, you can spend a few days, or even weeks, on ikebana guidance;
- It is not convenient to implement version control, because without a file you can’t find that for GIT, and for SVN. Especially when there are several dozen projects and not all of them have the same coding style.
Source: https://habr.com/ru/post/111977/
All Articles