Implementation of code style in development
Good day,% username%
I want to share my successful experience in the implementation of automatic verification of code styles in a project and tell what rakes they attacked. Publish opensource community tools that were created to solve the problem
A little bit about our project: PHP site, lies in the git repository of 2Gb, consists of 20k php files, the age of the project is 10 years, currently we have 15 developers. For code review, use atlassian stash . All development is carried out within the framework of separate branches, which, after passing the code review, are poured into the master and deployed to the prod
For a start, the question is: why? Why even follow the code styles?
The answer for me is simple: the code is written once, and then read by dozens of people over the years. Consequently, the cost of maintaining the code is many times the cost of writing. And if so, then it is worth spending a little time and formatting the code according to no one standard.
')
The first thing that came across: what standard to choose? We did this - we created our own standard, inherited from symfony, and we make changes there according to our idea of ​​beauty. We simply threw out some rules as impossible in our project for old classes (for example, the fact that any class must be inside the namespace). Good phpcs is a good opportunity to customize code styles
Second: how to check the code? What are the utilities for this? After a brief search, we stopped at phpcs, as there is native support in phpstorm
Third: what to check? Our whole project is huge, it was written over a decade by many generations of developers. Errors in the styles there are simply Nemer. Therefore, they decided that it is necessary to check only those strings that were changed by the developer within the framework of this task.
Third: how to actually check the code?
There were different options
A little bit about the architecture of the tool:
1) When pushing to some branch, the webhook jerks the phpcs-stash and transfers the name of the branch where the push was made
2) phpcs-stash requests the stash with all the reviews (pull requests) from this branch, goes through all the files (pulls them from the API as well), checks the styles, unsubscribes where it found an error. If there are no errors, adjust the review. The robot is unsubscribed only in modified lines.
The result looks like this:
3) When re-pushing, the robot re-checks all reviews, deletes comments about the corrected errors
For lovers of pictures:
With this approach, we still have the opportunity to customize native integration between stash and jira (for example: do not allow the task to be closed if the code review is not approved by the robot). And there is a great opportunity to analyze what errors happen most often, which would refine the verification rules
Since the verification system is not aware of anything other than the atlassian stash, it was decided to make it oriented in open source. Initially, it was done only for PHP, but the guys from the neighboring department liked it and they did support verification of C ++ code
For quick feedback, use phpstorm, which can integrate with phpcs. It looks like this:
What's next?
There is an idea to make the checker interactive: so that you can respond to the robot's comment “correct”, and the robot would correct the error itself if it can be corrected (for example, the missing space). But, unfortunately, I did not find tools that can fix styles in a particular string. If the community prompts, I will be glad
References:
I want to share my successful experience in the implementation of automatic verification of code styles in a project and tell what rakes they attacked. Publish opensource community tools that were created to solve the problem
A little bit about our project: PHP site, lies in the git repository of 2Gb, consists of 20k php files, the age of the project is 10 years, currently we have 15 developers. For code review, use atlassian stash . All development is carried out within the framework of separate branches, which, after passing the code review, are poured into the master and deployed to the prod
For a start, the question is: why? Why even follow the code styles?
The answer for me is simple: the code is written once, and then read by dozens of people over the years. Consequently, the cost of maintaining the code is many times the cost of writing. And if so, then it is worth spending a little time and formatting the code according to no one standard.
')
The first thing that came across: what standard to choose? We did this - we created our own standard, inherited from symfony, and we make changes there according to our idea of ​​beauty. We simply threw out some rules as impossible in our project for old classes (for example, the fact that any class must be inside the namespace). Good phpcs is a good opportunity to customize code styles
Second: how to check the code? What are the utilities for this? After a brief search, we stopped at phpcs, as there is native support in phpstorm
Third: what to check? Our whole project is huge, it was written over a decade by many generations of developers. Errors in the styles there are simply Nemer. Therefore, they decided that it is necessary to check only those strings that were changed by the developer within the framework of this task.
Third: how to actually check the code?
There were different options
- As you know, git supports server hooks. You can check the styles on the server side and keep them from running until errors are corrected. But I didn’t like this approach, since it’s not very convenient to push buttons with git in the console :) Plus, it’s impossible to make a workaround when it’s impossible to correct any errors in styles for some reason (for example, you need to rename the name of the method that used in 100,500 files)
- After some thoughts, it was decided that the ideal option would be when the robot would unsubscribe itself in a pull request about the found errors in the styles that the developer already had to correct. At the same time, at the first stage, we allowed some errors not to be corrected, if this required essentially refactoring, we modified the check rules that were convenient for us. So the tool was born - phpcs-stash
A little bit about the architecture of the tool:
1) When pushing to some branch, the webhook jerks the phpcs-stash and transfers the name of the branch where the push was made
2) phpcs-stash requests the stash with all the reviews (pull requests) from this branch, goes through all the files (pulls them from the API as well), checks the styles, unsubscribes where it found an error. If there are no errors, adjust the review. The robot is unsubscribed only in modified lines.
The result looks like this:
3) When re-pushing, the robot re-checks all reviews, deletes comments about the corrected errors
For lovers of pictures:
With this approach, we still have the opportunity to customize native integration between stash and jira (for example: do not allow the task to be closed if the code review is not approved by the robot). And there is a great opportunity to analyze what errors happen most often, which would refine the verification rules
Since the verification system is not aware of anything other than the atlassian stash, it was decided to make it oriented in open source. Initially, it was done only for PHP, but the guys from the neighboring department liked it and they did support verification of C ++ code
For quick feedback, use phpstorm, which can integrate with phpcs. It looks like this:
What's next?
There is an idea to make the checker interactive: so that you can respond to the robot's comment “correct”, and the robot would correct the error itself if it can be corrected (for example, the missing space). But, unfortunately, I did not find tools that can fix styles in a particular string. If the community prompts, I will be glad
References:
- phpcs-stash - https://github.com/WhoTrades/phpcs-stash
- Atlasis Stash REST API - https://developer.atlassian.com/stash/docs/latest/reference/rest-api.html
Source: https://habr.com/ru/post/303348/
All Articles