Note: in this article when I refer to a commit, I mean the commit you plan to share with the rest of the team, if you have local commits that you plan to amend/combine, I am referring to the final result.

In time you will find these easier to do as you develop, however, all of these are valuable before checking in!  The pre commit review is a nice time to polish what might have been several hours of intense work, during which these things were the last things on your mind!  If you are concerned about losing your work in the process of responding to these questions, first do a check-in and amend it as you go (assuming you are using a tool such as git that supports this), rolling the result into one nice commit for everyone else. 

Did you review your commit, change by change, with a diff utility?

• If not, this is a list of reasons why you might want to start!

Did you test your changes?

• If the test is valuable to be automated, is it?
• If it’s a manual testing scenario, did you at least try the basics manually?

Are the additions/changes formatted consistently with the rest of the project?

• Lots of automated tools can help here, don’t try to manually format the code, that’s a waste of time and as a human you will fail repeatedly.
• Are these consistent: tabs versus spaces, indentation, spacing, braces, line breaks, etc
• Resharper is a great example of a tool that can automate this for you (.net)

Are naming conventions respected?

• Did you accidently use abbreviations, unless you have a good reason to use them?
• Does capitalization match the conventions in the project/language?

Are files partitioned?

• Sometimes we add new code in existing files in a pinch, it’s a good idea to split these out if they don’t belong
• ie: are new classes defined in new files, if this is something your project values?

Is there commented out code?

• If you are removing an existing feature, get rid of it, that is why we have VCS
• If it’s not done yet, then why are you checking it in?
  • Perhaps a stash commit (git)?

Did you leave debug or unnecessary changes?

Do you understand all of the changes?

• http://geekswithblogs.net/wesm/archive/2012/04/11/programming-doesnrsquot-have-to-be-magic.aspx

Are there spelling mistakes?

• Including your commit message!

Is your commit message concise?

Is there follow up work?

• Are there tasks you didn’t write down that you need to follow up with?
• Are readability or reorganization changes needed?
• This might be amended into the final commit, or it might be future work that needs added to the backlog.

Are there other things your team values that you should review?