Verify compliance with the coding standards for PHP through git
In the development of the project are often involved developers of different levels. This leads to the fact that there is no strict format for writing code. The quality of the code on the project has to be constantly monitored by senior developers, and this takes a lot of time from them.
In order topunish govnokoderov to alleviate the suffering of those who make review of the code, you can use automatic code verification tools that everyone has known for a long time. This is PEAR and PHP Code Sniffer.
Most of the projects of the company where I work are made on Drupal, so an example of checking compliance with Drupal coding standards will be considered, although all of the tools described below can be applied to other standards, such as Zend.
')
More recently, a set of rules has appeared for testing Drupal coding standards via PHP Code Sniffer. Install and configure it is very simple, the most difficult thing starts next. How to make everyone check their code? The influence of the human factor affects, the first one forgot, the second did not want to, and the third simply believes that its code cannot contain errors and in general all this is a waste of time.
The solution could beforced voluntarily-enforcing the introduction of verification code in the development process. In order for us not to have to stand with a stick over each programmer, we will use the git version control system. Thanks to git hooks, you can easily add your own scripts to be executed with certain git operations, for example commit.
The first step is to add a code verification script to the pre-commit hook. When the developer commits his code, the modified files will be automatically checked. If errors are found, the commit operation is interrupted and a list of errors is displayed:
The code can only be committed when all errors are corrected. Great, now we don’t allow adding “bad” code to the project repository! But there is still the human factor. Again, someone forgets to add the verification script to the .git / hooks folder of his project, someone is too lazy to correct errors and he sets aside for later, etc., and the “smartest” simply use git commit --no-verify, because now they are not up to mistakes. In the latter case, git will not invoke the pre-commit hook and the modified files will go to the repository without verification.
To deal with this, we use the post-receive hook. This hook is triggered after adding the code to the remote repository. The script that will be called in a post-receive hook checks the modified files for errors and sends a report to the mailbox of one or more senior developers who are responsible for the quality of the code on the project.
The report sent by mail looks like this:
Thus it is easy to automate the process of monitoring the quality of the code on the project.
Strengths of this method:
Disadvantages:
Resources:
UPD 05/19/2012:
Added the ability to ignore file scanning using the configuration file.
In order not to check some files and directories, you need to create a .hooks_ignore file in the project root. Then put in it the paths to files and directories that you do not want to check. This may be the core of the engine or third-party modules.
Sample content for .hooks_ignore file
The first two lines allow you to exclude from checking the full directory with all the files inside, and the third excludes a specific file.
For added convenience, the .hooks_ignore file should be brought under version control, so that it is also stored in the repository and is shared by all developers on the project. And also so that post-receive hook can use it when checking in a remote repository.
The source code for Drupal.org and GitHub has been updated.
I am waiting for your wishes and comments on this small project.
In order to
Most of the projects of the company where I work are made on Drupal, so an example of checking compliance with Drupal coding standards will be considered, although all of the tools described below can be applied to other standards, such as Zend.
')
More recently, a set of rules has appeared for testing Drupal coding standards via PHP Code Sniffer. Install and configure it is very simple, the most difficult thing starts next. How to make everyone check their code? The influence of the human factor affects, the first one forgot, the second did not want to, and the third simply believes that its code cannot contain errors and in general all this is a waste of time.
The solution could be
The first step is to add a code verification script to the pre-commit hook. When the developer commits his code, the modified files will be automatically checked. If errors are found, the commit operation is interrupted and a list of errors is displayed:
The code can only be committed when all errors are corrected. Great, now we don’t allow adding “bad” code to the project repository! But there is still the human factor. Again, someone forgets to add the verification script to the .git / hooks folder of his project, someone is too lazy to correct errors and he sets aside for later, etc., and the “smartest” simply use git commit --no-verify, because now they are not up to mistakes. In the latter case, git will not invoke the pre-commit hook and the modified files will go to the repository without verification.
To deal with this, we use the post-receive hook. This hook is triggered after adding the code to the remote repository. The script that will be called in a post-receive hook checks the modified files for errors and sends a report to the mailbox of one or more senior developers who are responsible for the quality of the code on the project.
The report sent by mail looks like this:
Thus it is easy to automate the process of monitoring the quality of the code on the project.
Strengths of this method:
- Centralized control;
- You cannot completely avoid checking the code;
- Code verification scripts do not change the source files and do not block the addition of code in the case of a hotfix;
- Scripts are easy to install and configure;
- In addition to the errors of the Drupal coding standards, functional errors are displayed. For example, that you forgot to use the function t or check_plain (and this is a security hole) when displaying data on the page.
Disadvantages:
- If you add this tool in the middle of development, all the old errors will manifest and at first it will be difficult to clean them.
Resources:
- Drupal Code Sniffer
- A set of scripts to automatically check the code through git
- Instructions for installing and configuring scripts in Russian
UPD 05/19/2012:
Added the ability to ignore file scanning using the configuration file.
In order not to check some files and directories, you need to create a .hooks_ignore file in the project root. Then put in it the paths to files and directories that you do not want to check. This may be the core of the engine or third-party modules.
Sample content for .hooks_ignore file
includes
sites/all/modules/contrib
sites/all/themes/garland/template.php
The first two lines allow you to exclude from checking the full directory with all the files inside, and the third excludes a specific file.
For added convenience, the .hooks_ignore file should be brought under version control, so that it is also stored in the repository and is shared by all developers on the project. And also so that post-receive hook can use it when checking in a remote repository.
The source code for Drupal.org and GitHub has been updated.
I am waiting for your wishes and comments on this small project.
Source: https://habr.com/ru/post/141447/
All Articles