Skip to content

Code Review Tips

Volume IIEntry 57 of 67 in 20132 min read

Written by Gloria Metrick on . Published as written. It may not reflect how these systems work today.

Years ago when I was still a fairly new programmer and had not been through many code reviews, I got the best piece of code review advice that I've ever received. Yesterday, it just happened to be appropriate to pass it along at a code review to others so that they could receive the same benefit from knowing it. Today, I'm passing along to those of you reading this blog.

Best Code Review Tip Ever
"Don't be clever." Yup, that's it. Let me explain it further -- whatever you do in your code, if you come up with something extremely clever and are just way too proud of it, it's going to be the most likely thing that the code reviewers will ask you to change. The reason is this: this clever thing came to you and you understand what it is, but the person supporting the code doesn't have a lot of time to sit thinking about what you did in there. That's why the code reviewers will often make you take out your clever thing and replace it with some standard and boring thing.

Bonus Tip

Since I did give the title "tips" rather than "tip" I put the pressure on myself to give the reader more than one tip. Here's the second. It's so obvious that I feel almost as if I'm cheating the reader by making it the second tip, but let's just make it obvious: Reviewers need to read all documents before the review. If the reviewers are discovering things as they go along, and especially with complex code or situations where there is a lot of code to get through, it is just going to take you too long to discover things as you go. It's like any other meeting -- if you all go in prepared, the whole thing will go faster. Unless you love to sit in endless meetings and, then, just wing it.  ;-)

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/

Comments

No comments were left on this entry. Comments are closed.

Working on the same problem in your lab?

Talk to a laboratory informatics scientist