Effective and accurate code developers, not unlike writers or other professionals, know the importance of having their work reviewed by a peer. No matter how much they excel at what they do, a code review will catch any "typos" or little mistakes made that may otherwise be overlooked.

Code reviews are the systematic examination of software code and while they should be meticulous, they don't have to be a laborious or formal process in order to be effective. Efficient and lightweight reviews are thought to capture thousands of small bugs each year.

Peer review methods can vary, but there are some specific practices widely accepted amongst industry professionals. Structured enough to be useful, yet flexible enough so as not to stifle creativity or slow projects down, they help ensure that code produced is more likely to be error-free.

Studies have proven that in the organisation of software maintenance, up to 55% of one-line changes were made in error before peer reviews were introduced. Once code reviews were conducted, that percentage dropped significantly, to 2%.

Here are a few tips on effectively reviewing code that are useful to note, whether you're the original developer or the reviewer:

1. Review only 200 to 400 lines of code at a time. According to research conducted by Cisco, doing more can be overwhelming and less can defeat effectiveness. Reviewing in this manner, spread over 60 to 90 minutes, will provide you an excellent yield of 70 % to 90% effectiveness.
2. With that goal in mind, aim to review 300 to 500 lines of code per hour. Remember, faster is not better. Yes, you want to manage deadlines and effectiveness, but rushing, missing errors and having to come back to a project will slow you down even longer than if you take the time to do a great review initially.
3. Don't review for longer than 90 minutes at a time. Otherwise, you'll start to lose what makes you essential to the original code developer – "fresh" eyes. Once you get tired, you might start to miss little defects, lowering your correction rate. In fact, this isn't limited to coding. It's well known that in any concentrated effort, humans lose effectiveness after 90 minutes.
4. Request that developers briefly annotate their work first before sending it to you. If they take a second look at it before sending it your way, this will help eliminate errors. The review process will lower bug findings even further.
5. Create checklists to improve results. As omissions are the hardest errors to overlook, a specific list of what to look for will aid in increasing accuracy. Confirm all bugs are handled, that function arguments are tested for invalid values, that unit tests have been created, and that any personal flaws you identify in your own work habits are addressed.
6. Establish pre-determined goals for code review, and capture metrics so you know how to improve. These may include "drop bug discovery below 10%" or "reduce support calls by 30%." Depending on the project at hand, these goals may differ, but by setting them up in advance you will know whether your efforts were successful.
7. Verify the defects are actually repaired. If you're going to put in the effort to identify them, double-check that they are functioning afterwards. This may seem obvious, but you'd be surprised how many times errors are pointed out and never actually fixed.
8. Work towards reducing "my code" mentality. It's important to take ownership of our work, but at the same time not feel overly sensitive about making improvements or correcting errors. Constructive criticism and growth opportunities make for more accomplished professionals, and having someone else perform a code review will help to diminish feeling sensitive about the work done.
9. Develop a sense of teamwork and good code review culture. A step further than reducing "my code" mentality, it encourages everyone to get involved, not just the developer and the reviewer or team leader. If the "holy grail" is a truly cross-functional team, this is a leap in the right direction.
10. Don't consider a project done until code is reviewed and errors are fixed. Only when the software is functional and virtually free of bugs can it be considered complete or judged as a success.

Case studies by Jet Propulsion Laboratories have revealed that code reviews can save upwards of $25,000 US dollars per project inspection. Furthermore, IBM has shown that errors were reduced to 1% of what was typically expected.

The results don't lie - reviewing code is a worthwhile investment, which pays for itself in overall time saved, positive results and happy users.