Comparing source code on check-in and check-out

A great practice I follow is to do compare when checking in and out some source code.

When in a new project (my current situation) it's really fast to find out what code is hot - heavily changed, and how it is changed. Even when into the project, the new guy can follow what others are doing, can find out if someone accidentally overrides something (it happens more often than you think), and generally keep track of what everybody's doing.

There's an overhead involved - the whole procedure needs some time. I try to commit (check-in) relatively often, and on every sync I do compare. This way the committed code by others could not pile up.

There are also tricks to optimize the process - if the comparator highlights horizontally changed code (most of them do comparison only vertically - line by line) you can ignore code formatting changes faster, because no code is highlighted. If some refactoring takes place, you could ignore the changes in subsequent files after you've seen them in the first one. Example (only spaces and quotes changed):

A good reason for frequent commits is that a frequent update would be easier - when you update a file you see a single change.

Comparing code on commit (check-in) makes some bugs obvious and helps avoid typos. Frankly I don't do it always.

Two additional things I would recommend: when committing, write a description (it helps others understand what's going on) and do atomic commits - commit a single task as one thing (select all changed files and commit them together with an understandable description - it's really helpful for the guy after you.
Note: not all repositories support atomic commits, but still it's a good habit.

The second thing is always to update before commit - avoid partial commits and breaking the build accidentally.