I like to think of coding as rock climbing in this context. You climb a bit, and then you put an anchor in the rock. Should you ever fall, the last anchor you planted is the point that secures you, so you'll never fall more than a few meters. Same with source control; you code a bit, and when you reach a somewhat stable position, you commit a revision. Should you ever fail horribly, you can always go back to that last revision, and you know it's stable.
That said, if you work on a team, it's customary to make sure whatever you commit is complete, makes sense, builds cleanly, and doesn't break anyone else's stuff. If you need to make larger changes that might interfere with other peoples' work, make a branch so you can commit without disturbing anyone else.
It also depends on the SCM system you're using. Distributed systems typically make merging and forking painless and fast, and you can commit locally; this means you should commit a lot, and push / merge when you have done a substantial amount of work. With centralized systems such as svn or cvs, committing is more costly, and it affects everyone. Branching partially solves this issue, but because it happens on the server, it can be painfully slow, and merging can be cumbersome. So with centralized SCM's, there is often a more careful culture, where you only commit once you've done significant amounts of work.
As for the add-on: Please, please don't do that. Lines of code, number of commits, number of bugs found / resolved, etc., are all very bad measurements of quality or even quantity.