Tidy First?

Chapter 16. Separate Tidying

We’ll assume for the moment that you use a pull request (PR)/code review model (I’ll argue for an alternative later). Where do you put tidyings?

Here’s an ugly piece of tail chasing:

1. I put my tidyings in with my behavior changes.

2. Reviewers complain that my PRs are too long.

3. I separate the tidyings into their own PRs, either before (more likely) or after the behavior changes.

4. Reviewers complain that the tidying PRs are pointless.

5. Go to 1.

The tidyings have to go somewhere, or you don’t tidy. Where do they go? Summary: they go in their own PRs, with as few tidyings per PR as possible.

Let’s go through the trade-offs in more depth. Folks learning to tidy seem to go through predictable phases. In the first phase we’re just making changes, and we begin with an undifferentiated mass of changes (Figure 16-1).

Figure 16-1. Undifferentiated mass of changes

Here, we’re in the middle of fixing an if statement, realize a name is wrong, fix that, and go back to the if statement. Change is change.

After learning the tidyings, it’s as if our picture under the microscope snaps into focus. Some of those changes were changing the behavior of the program, its attributes as observed from the running of the program. Some of those changes, though, were changing the structure of the program. Those changes can only be observed by looking at the code: B=behavior, ...