The problem with these metrics is that they only detect bad code, and they're not very sensitive. In other words, a good score doesn't mean your code is good; it just means it's not hideous. They don't tell you anything that isn't obvious just by looking.
You're better off using collective ownership and pair programming or code reviews if you're interested in improving your skills.
Edit The issue is that "code quality," once you're past the novice level, is really about design. It's about how maintainable and understandable your entire system is to humans. It's very subjective and context-sensitive, and it's the kind of judgment question computers are bad at.
It's kind of hard to game -- reducing CRAP is easiest with a test or refactoring.
On the last team I was on, we kept an eye on it, but didn't do anything systematic.
If you want to derive a quantitative metric from that, I guess you could take the average number of lines/time required to change or extend something.
Other coders user SPM/SPH but it is essentially the same thing.
Oh, you said quality, not quantity...
Same answer.