Ch-ch-ch-changes

This morning my colleague and I were discussing some code he had recently committed. Since we are both working on intertwined projects, I found myself stepping over (and into) his code, and when I noticed his "style" of doing things differed slightly from mine, I called him on it.

In the end, he made some changes, and I made some changes, and the topic of what to do about legacy inconsistencies came up, and he offered up this gem:

My philosophy is:
1) Change what you do in the future first.
2) If time permits, and the change is easy, change code at or near code that you're already working on next.
3) If you're dying of boredom, change old (unused?) code that's not being worked on.

I can agree with that. It's essentially what I already do, but seeing it in writing made it somehow more officious. It's department policy material if I ever saw some.