3 ms·
> Never fix a bug and refactor in the same pull request. We’re kinda going the opposite way: If you find something that should be fixed, then fix it. This is,
by janaagaard 4y ago
> Never fix a bug and refactor in the same pull request.
We’re kinda going the opposite way: If you find something that should be fixed, then fix it.
This is, of course, meant for small things, like renaming or rewriting expressions to make them more readable. But we have had to make this change, because our experience is this is necessary to avoid code rot.
- shepherdjerred 4y agoI think that the two ideas are separate. You should fix problems that you see, but you should do this in separate commits (and ideally PRs). There are a few benefits If your refactor is large, you can get a bug fix in ASAP in a small PR, and get the large PR reviewed later. Sometimes I’ve done a refactor with a stubborn CI integration test or two that might take a few days to fix due to long feedback cycles. Aside from that it lets your reviewer enter a different mindset for each change. The bug fix is more easily understood, and the reviewer expects a change in behavior. For a refactor the reviewer can usually review in a more relaxed manner because they know the behavior can/should be the same, and good unit tests should identify any differences in behavior