Make reviewer's job easier by keeping non functional changes separate.
-
If refactor and functional change is mixed in the same commit it adds extra burden to the reviewer.
What to look for in non functional vs functional changes are quite different. When looking at a non functional change the reviewer should be on the qui vive for functional changes.
If it is mixed in the same commit it means that the reviewer must first understand if each changed line is supposed to be a functional change or not, and then if it actually is that.
By putting the refactor in a separate commit the reviewer can stay in the same mindset during review of the full commit and look for functional changes.
This also helps archaeology. When inspecting a range of commits in the hunt for something that introduced some bug it is more likely that it is one of the non-refactor commits. So the first pass over the commits would skip over the refactor commits.