Code Reviews

Our teams haven’t instituted any formal process around code reviews. It’s more of an informal chat about code. I’ve been reading/skimming Practical C++ Programming (in preparation for C running in the AVM) and came across these metrics:

• The number of lines reviewed
• The time spent reviewing the code
• The number of defects found
• The defect density (defects per line of code) — computed
• The review rate (# lines reviewed per hour) — computed

So, on the one hand it’s nice to have these numbers. It helps you prove the idea to the business and also stay on task. On the other hand, the author (Steve Oualline) only is getting metrics against bugs. And this is intentional on his part. He wants to keep style and even architecture comments entirely out of the code review.

I’m not sure I agree. I think some of the best feedback I have received have been design or style comments. Comments like “it’d be cool if that we had an interface class for that” or “why is that a singleton?” can really help improve the design of the code. What about adding this metric?:

• The number of design suggestions implemented upon refactor

« uint and int reflection crazyness

Mate Framework (an unfair review) »