We all make mistakes. It is OK to make them. Code reviews are an opportunity to learn from others while detecting those errors.
Mistakes can exist in the form of bugs (where your code doesn't do what it is supposed to), style (where you might be using the wrong coding style) or design (not using the correct design pattern or may be you just took a wrong approach to the problem).
Design mistakes could be addressd before coding, when there is a small cost of change, using design reviews. This will lead to a better understanding of the solution by the team, and most probably, to a better design.
Let's return to code reviews:
Seize the opportunity of a code review to learn and discuss, but don't take it personally!
There are many different formats for code reviews, these are some of them:
- In ad hoc reviews, you ask for help on demand, when you have a doubt and need some guidance. You will happily find how every programmer enjoys being asked for their opinion :-)
- With a buddy system, you are assigned (or you choose) someone who will review all the code you commit. Remember: solid code is better than odd code.
- In a high-level review, there's usually a meeting where some bunch of people reviews your work of several weeks paying special attention to design decision (the high-level ones). The tests are a great way to start presenting your code.
- A line-by-line review, normally takes place when the code needs a serious review (due to a bug?). If you are the one reviewing the code, be careful and take into account all possibilities and assumptions being made.
- An audit, is a deep review made by someone knowledgeable. The writer of the code will face a lot of questions, from bottom to top, from data structures to design decisions. Try to make yourself these questions while you are programming.
Tips for code reviews:
- Obtain a list of the files you've changed.
- Get a diff for each changed file.
- Review your changes yourself (!). Most likely, you'll find some mistakes in this step.