Sorry it’s been so long, China was very busy and getting back is slightly hard to settle into. Nothing like a 16 hour plane ride (and getting stuck), plus the time difference to throw off a schedule. Also, I’ve been really trying to get use to complex analysis, so I haven’t had much time.
Today, lets discuss code reviews. For the past few months I’ve been programming primarily in C++. For this article, you should know two things about C++:
- It is a massive language
- Unless you’ve been programming in it for longer then I’ve been alive, you probably aren’t a master in it.
The second point might not be completely true, but it’s a language with many intricacies. Pointers and reference (namely memory management) are very hard to keep track of. You tend to spend a lot of time wondering which object owns what data. For the sake of speed you want to keep ownership minimal and pass around pointers, but for safety you want to simplify ownership models.
Okay, so how does this relate to code reviews? I’m fairly new to C++, I tried to quickly learn more by reading Meyer’s books (Effective C++ series). It’s a great series, please do yourself a favor and read it. But a master it does not make you, and every company has there own style guides. To get my code okay-ed, I need a known competent C++ programmer to okay it.
Usually I turn to a person on my team, this mostly guarantees quick turn-around time. Here’s the problem, usually only one person on your team is so qualified to okay your code. Quickly you get use to what that person wants, and you start understanding their style, not your companies style. Your teams style diverges from the company, and it’s hard to integrate with the larger company!
My suggestion: have someone on a different team, who doesn’t know your team, check the style. Sure, they may be oblivious to what your team needs, but this will make sure your code, and your personal style, stays in line with the rest of the company. Just make sure it’s not for every change, because we need to write code sometime!
