I’m not opposed to the philosophy of improving code incrementally, but doing this can result in reduced productivity and more bugs, which I want to avoid.
Non-functional improvements to code in the same pull request may
- introduce bugs
- make it harder to revert cleanly when a code change is discovered to be buggy
- obligate us to perform more testing, decreasing velocity
- add noise to the Git log, making it harder to find things
- require more time from the code reviewer to understand the change
- increase overall time in code review, as more lines changed also increase opportunities for more feedback and waiting
My understanding of “cleaning up code along the way” means to change code around the area that I’m currently working in, however, requiring our team members to follow a non-linear path while reviewing a PR can be discouraging and waste time and energy. Let us change the code in the current work area immediately before and/or after the work is done.
Try not to make code improvements in a pull request when the primary intent of the PR is not about those kinds of improvement. It is fine to create “improvement-only PRs”, but they should not have behaviorally irrelevant changes in the same pull request. If you’re uncertain whether to keep the code improvements in the same PR (as separate commits) or in separate PRs, default to separate PRs.