Prepare code for review

Code review from other internal team members is a valuable part of the development workflow. By following these guidelines, reviews and feedback can be more quickly received, and a pull request can be more quickly approved.

Before creating a pull request, prepare the code for human review.

Scan the updated code locally with PHP Code Sniffer using the VIP Coding Standards. Address any issues reported in the PHPCS feedback output.
Remove unused or unnecessary code from the branch that does not need to be reviewed.
The developed code in the pull request should be complete. No further changes should be needed except to address feedback from the VIP Code Analysis Bot and a reviewer’s comments.

Reduce the size of a pull request

Pull requests with changes that affect more than 1000 lines of code can be overwhelming for a reviewer and will slow down the review process. If the code changes in your commits affect more than 1000 lines of code, break the changes into smaller, separate pull requests.

A suggested workflow for creating smaller pull requests:

Check out a new branch off of the main production branch.
Check out one of the changes from the branch used in the large pull request.
Push this change to the new branch.
Commit and push up the new branch.
Create a new pull request from this branch targeting the main production branch.
Continue to do this until all of the changes found in the original large pull request are now included in the smaller pull requests.

When to create separate pull requests

Separate pull requests should also be created for:

Extensive whitespace changes (e.g., fixing tabs and spacing)
Changes that are limited to style only (e.g., revising variable names, formatting, comment blocks, etc): Pull requests that contain only CSS changes—or do not contain any files with extensions that are not reviewed by the VIP Code Analysis Bot, such as PHP and JS—will be auto-approved.
Addition or removal of a plugin: Create a separate pull request for each plugin added or removed. This makes it easier to rollback to a previous state if issues occur after the pull request is merged.
A build step that results in minified or compiled JS and CSS: Setting up branches with continuous integration and deployment (CI/CD) may simplify this process.

After creating a pull request

Review the pull request in GitHub and confirm that only intended changes are included, especially if there are changes made to .gitignore.
Avoid making changes to a pull request that has already been approved. If possible, make additional changes in another branch, or wait until the open pull request has been merged.
When making changes in response to a review, minimize the number of new commits in order to simplify the reviews that are needed.

Last updated: March 10, 2026