In my experience the best way is to let the hole team to make the code review. We use a commit mailinglist in each project where you can follow every code changes to the version control system. Most of our developer have subscribed to their project specific mailinglist because they are interested at code changes.
When someone notice a bad way in the new source code he either explains the committer how he can do it a better way, if the committer is a trainee, or he begins a discussion about it, if it was a more experienced committer.
Of course this method does not guarantee that all new code is reviewed, especially in stressful times when no one of the team member has leisure to follow each code change. Also not every developer is responsibly to ensure that every developer makes his job good, alone of this you can not guarantee that it is reviewed. But, at least in our teams, there is always a technical manager who is responsible for technical quality.
I am a real fan of code reviews if they conform to following scores:
- every developer has the possibility to review all code and argument to his opinion
- no one has the right to abuse others code
- not only bad code activate a discussion but good code too
- the discussions ends with happinesses for every involved people
- the review occurs nearly in real-time, at least before feature is completed
What I have learned is that if you are someone who review each line of code and think you have to control such things like code quality in terms of code formatting or code efficiency then you self are very inefficiency because you do things what machines can do for you. Your target should be to use a continuous integration system which controls the build and code quality of each code contribution. If this system generates reports and sends them to the contributors everything is perfect.
I must admit that if you have to review the code because you have to control, or to rank the quality of a programmer, then my suggestions does not make sense. In this case I would also not review the source code line by line. I would review things like:
- are there security relevant issues
- are intended APIs used
- did the code apply the specified architecture
- did he write useful tests (but only if he was instructed implicit, I had to learn)
- ... and some more, probably
If you are an experienced developer you will definite always find things like loops which you could do with better performance. Of course it is useful to explain others such knowledge but this should be not part of the review session. If there are significant performance issues then not because he (or she) used a less efficient variant of a list type.
Because the initial question was why some people seems to make a better review as other people I would answer that these people perhaps make a preview before the real review begins, means they probably are prepared them self so that they know exactly what they want to review.