I spent a lot of time thinking about the little things that we do that affect software development. When things are easy, people tend to do them. When they are hard, they don't do them as much. That much is self-evident. The thing that we often forget is that code is the sum of all of the things we do in relation to it, so we shouldn't be surprised when process-y and language things affect our code.
The thing I'm wondering about now is our practices around using diffs in our version control systems. It just stands to reason that looking at diffs of source code before we commit our changes is a good thing. The code was one way and, looking at a diff, we can see how it is different and hopefully give ourselves a nice pat on the back when we check in our changes or submit them for review. It all seems good, except when it isn't.
The other day, I took a nasty 20 line method and refactored the hell out of it. I took some deeply nested conditionals and turned them into guard clauses. It looked great, the tests passed, everything was happy-making except for the diff. It was absolute garbage. Lines of code moved in ways that git couldn't conceive of. Bumping up the --inter-hunk-context of the diff made it a little better, but it was still a mess. I realized that I didn't want to look at the diff any more. I just wanted to see the full body of the affected method before and after my changes. Oh, and I also wanted to see whether I added new tests or changed existing ones.
It's funny, I don't think that traditional diffs are broken, but I do suspect that they are less important for refactorings. At the end of the day, we care whether we are modifying behavior, not code. And, methods, at least, have most of their behavior bounded by their interface. Lines of code don't have an interface. You always have to see line changes in context to know what is going on.
So, yes, I use diffs like everyone else, but I can't help thinking that there is something wrong about it. I have the sneaking suspicion that it is so easy for us to let methods grow without bound because we look at line oriented diffs and say to ourselves "oh, it's only adding three lines." Conversely, many people might not aggressively alter method structure during refactoring because the first time that they do it, they find the diff incomprehensible.
When things are easy, people do them often. When they are hard, they don't do them quite as much. It makes sense to pay attention to the affordances of our tools.