Start by thinking about TDD and the psychological reason why TDD is good: it shows you red turning to green, effectively rewarding you for the done job.
Now I've stepped into a project with such a scrambled source code that I find myself constantly refactoring while doing other tasks. Sometimes the refactoring gets bigger and turns into a standalone job and this is the case when I'd love to see a line like this one on my display after I'm done: Great job, you maintained all the functionality, all tests pass, the code base is smaller and easier to understand!
Ok, I'm giving the tools too much credit ... I'll run the tests myself and ensure the functionality is preserved. But hey, what about the code base is smaller and is easier to understand! To a big extent I think the shorter the better, and to skip the debate let's take the proof to the extreme, just go through the C - Cobol code comparison here and see which one is easier to grasp. You're right, the shorter one.
This means you can measure (part of) the success of a (big) refactoring with a metric derived from SLOC, along the lines of effective SLOC, this as long as the tool that computes this metric for you is smart enough to yield the same results for:
andi++;andi = i + 1;
P.S. Guess what, I've edited the post and made it shorter ;)void m() {and
date = new Date();
}void m() {
n();
}
void n() {
date = new Date();
}
1 comment:
yep, always gives me a feeling of beatitude reducing the LOC # through refactoring :)
(have you ever noticed that 'refactoring' isn't recognized by any spell checker? )
Post a Comment