Discipline to Habit
Oct. 8th, 2008 04:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeurOne of the less obvious reasons to be disciplined about good programming is precisely that, if you do so, it becomes steadily easier.
Consider: if you only refactor and clean up your code occasionally, then it's a painstaking project each time you do so. You have to remind yourself what it *feels* like to clean up your code. It's an intellectual exercise that takes a bunch of effort, examining it and trying to figure out which refactoring pattern to apply. As a result, it's not so much fun.
By contrast, if you do so *regularly*, it becomes a little easier each time -- no longer so much a matter of effort as of habit. The result is a virtuous spiral, producing better code every day simply because it's easier to do so than to produce bad code. The refactoring literature uses the metaphor of smell on code: Fowler's classic book on the subject is mostly an encyclopedia of "bad smells" to learn. Once you've done it long enough, the metaphor becomes more and more apt -- recognizing and replacing the bad smells gets downright instinctive.
I am reminded of this today, when I'm pretty braindead and attacking a new feature that didn't fit in with the grungy IM stack very well; as things would have stood, it would have required a bunch of duplicate code paths. But since I'm so used to refactoring the code (and have good enough test suites for it), I didn't even *think* about it before refactoring to clean up those paths. It was intuitively obvious that it had to be done, so even with my morning Clover buzz wearing off I could just shove code around until adding the new feature was just a one-line enhancement. Very satisfying, especially on a day where I'm not up for hard thinking...
Consider: if you only refactor and clean up your code occasionally, then it's a painstaking project each time you do so. You have to remind yourself what it *feels* like to clean up your code. It's an intellectual exercise that takes a bunch of effort, examining it and trying to figure out which refactoring pattern to apply. As a result, it's not so much fun.
By contrast, if you do so *regularly*, it becomes a little easier each time -- no longer so much a matter of effort as of habit. The result is a virtuous spiral, producing better code every day simply because it's easier to do so than to produce bad code. The refactoring literature uses the metaphor of smell on code: Fowler's classic book on the subject is mostly an encyclopedia of "bad smells" to learn. Once you've done it long enough, the metaphor becomes more and more apt -- recognizing and replacing the bad smells gets downright instinctive.
I am reminded of this today, when I'm pretty braindead and attacking a new feature that didn't fit in with the grungy IM stack very well; as things would have stood, it would have required a bunch of duplicate code paths. But since I'm so used to refactoring the code (and have good enough test suites for it), I didn't even *think* about it before refactoring to clean up those paths. It was intuitively obvious that it had to be done, so even with my morning Clover buzz wearing off I could just shove code around until adding the new feature was just a one-line enhancement. Very satisfying, especially on a day where I'm not up for hard thinking...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2008-10-08 08:36 pm (UTC)(See the writings of Cato the Censor to get an idea of how old this wisdom really is.)