It’s hard to do a code review if there are no published guidelines or standards. Each company should have this document, which itself must be updated and reviewed regularly.
You’re trolling, right?
If you aren’t, then I’ll just say that code reviews are supposed to be informal - no guidelines beyond look at the code and make sure the guy checking it in can explain what it does.
@chris24 nope.
But implying that all code reviews are informal with no guidelines beyond having someone explain what it does is exactly the opposite of what I’ve seen work.
well code reviews aren’t the only thing, it’s just a useful check on keeping bugs out of the codebase.
Hello??? Ren and Stimpy? (especially appropriate because most of the time you are saying to your partner, Stimpy, you Eeeediot!
Spongebob and Patrick
Oscar and Felix
Solid Snake and Raiden
Black Mage and White Mage
Aragorn and Legolas
Kirk and Spock (are you out of your Vulcan mind?)
I absolutely loved the cartoon about code reviews showing wtf/minute, it is just as funny as it is true. A colleague of mine happened to take a look at it and did not find it funny at all. Actually I had to explain the cartoon to him. As you might imagine he is one of those who writes a lot of wtf code. At my workplace there are few of us that understands that cartoon so finding a coding buddy, as important as it is, is not an easy task where I work. I think i will settle for a rubber duck that I can talk to when I have a need for feedback. That way I will be guaranteed to not get the usual crappy answers 
You can get really valuable lessons with this simple practice.
We do this religiously in my team (we try to find the time for it even if apparently there is none).
Right now my coding buddy is a former trainee (he finished serving his time like a year ago) and believe me, I have got great insight of things I did not considered, potential bugs, hard to read code, event method/variable naming corrections from him. So even if you feel like a all seasoned programing veteran, there is always room for improvement if you are humble enough to take advice from your peers regardless of their credentials or seniority.
Simon Nicol, I feel bad for you…
Programing is not a path that you can walk alone… at least not a lasting pleasant one.
70% of a good programmer skills are social, not technical.
I have worked in the game industry too and I find no resemblance of it in your words. I guess I never worked with someone you thinks we are demoted godlike rock stars. All the people I have worked with (including myself) feel more like mercenaries how enjoy it so much that could do it for free, but why do it for free if you can make a profit… with the exception for idealistically OpenSource projects.
I work on a development team consisting of about 25 active programmers, working on a very large insurance application that has about half-a-million lines of production Smalltalk code and probably a similar amount of unit and functional test code.
For over 5 years we’ve had a designated team of 5 or 6 developers acting as part-time code reviewers. Someone from this team must review every line of code - including the unit and functional tests - before it gets released to the current shared development stream.
This Code Review team has weekly meetings where issues identified during reviews performed in the previous week are discussed and shared within the team. We’ve seen a substantial improvement in overall code quality during the last 5 years but one of the big payoffs has been that this Code Review team has been exposed to pretty well all major aspects of our complex application. This allows us to be very effective in identifying common problems like duplicated code or code not being implemented in the ideal locations. We’re also well-placed to see opportunities for framework changes that other developers, focusing on solving just the problem-de-jour, might miss.
We have had excellent support from our managers but the success of our Code Review process has been predominantly due to the efforts of the development team itself.
How about Sherlock Holmes and Dr. Watson
This only works if done properly, and is done early in the process.
A place I used to work at, code reviews were done after you’ve done all of your work and it was supposed to be correct and accurate. If there anything they didn’t like or you’d make some insane decision (because you weren’t supposed to figure it all out yourself and not talk to anyone else) the senior team would complain to management.
As a non native English speaker I’ve been calling this pal programming instead of pair programming for years =)
90% of my everyday work consists of test-driven pair programming developing. I do really little code without my current pal, and I’m getting lazy about it. I enjoy every minute we spend sharing programming achievements and frustrations with someone.
So here is a thought: what is more efficient?
Obviate childish pairs of lazy irresponsible programmers expending more time in youtube than in their code.
(I would add Asterix and Obelix to that list of famous couples)
You forgot about Hardcastle and McCormick
Very much disagree with Max - reviewing other people’s work is one of my responsibilities as one of the more experienced team members, and I’d be seriously concerned if it looked to me that they were getting careless, expecting me to save them. If the coder is doing their job properly, the reviewer shouldn’t be doing anything more than suggesting ways something could be done better, not ways it’s been done wrong.
I think you left out B.J. and the Bear, Smokey and the Bandit, Tom and Jerry, and Butch Cassidy and the Sundance Kid…
Yeah self reviewing the next day does seem to work quite well although I am sure it doesn’t hurt having another pair of eyes.
the buddy system on school trips is i’m sure at least as much about making it easier for the teachers to be able to count the children
For the UK based programmers there is
Morecambe and Wise
Little and Large
Bill and Ben
French and Saunders
to name a few
For those review resisters they need to be pointed to the analogy that writing code is like writing a book or even producing a scientific article. An author will get the book edited before publication, a scientist will get their work peer-reviewed before publication.
My team recently took on peer review as part of our general approach to process improvement, and the impact on quality it has had is phenomenal. It uncovered some long standing problems with an approach one developer had used for a couple years, brought the team closer together, and gives everyone an opportunity to learn from each other.
While the initial perception from outside the team doing the reviews was that productivity was lower and a lot of time was spent doing these reviews, at the end of the release cycle the time has been more than recaptured in reduced defects and quicker time to complete regression testing.
If you plan to do this with a team, there is a great tool from Atlassian called Crucible that I would highly recommend. It makes the review process much easier, and can be tied into each CVS commit.
Karl’s book is excellent and anyone wanting to implement a whole code review process should get it.
My book on lightweight peer code review (free at http://smartbear.com/resources/whitepapers/best-kept-secrets-of-peer-code-review/) adds more data to the picture, specifically around less formal kinds of review like just buddy-checks (as you talk about), email pass-arounds, tools, and pair-programming.
It turns out a lot of the techniques in Karl’s book are unnecessary for a good ROI. Meetings, for example, take a ton of time and don’t contribute much to uncovering bugs.