This week, I had a code review with not 1….not 2….but 9 developers, at the same time. My first code review in a professional environment! This was part of the C++ Study Group I talked about joining last week. While terrifying, the experience was also very enlightening. I can’t post the code, so I’ll do my best to generalize the kinds of feedback I got and my general thoughts.

1. More Comments! Before the meeting, I reviewed my code to make sure it was relatively self-explanatory. I thought my variables were well-named, my comments explained intent, and my functions were small enough to be easy to follow.
   
   I quickly realized that I largely underestimated how much explaining I’d have to do on the spot. What do these nested loops do? Why are you declaring this variable at this scope? Why are you using an iterator here?
   
   My best analogy for the experience is: it’s like making a chocolate cake. I had spent hours studying the recipe, working with the batter, making test cakes, and then I brought my best cake to show the other chefs. But when I arrived, I just showed them the finished cake and expected them to understand. What I really needed to bring was the recipe with all my notes. Next time: more comments!
   
2. Always Ask “Why”? As we looked through the code, the group wanted to know why I made certain choices, on what I considered very basic decisions like:
   
   > Initializing variables
   > Using cout instead of printf
   > Why I used “\n” instead of endl
   
   I didn’t have good answers for these questions (partially because I’m not a strong C++ programmer) when I should have.
   
   Just because something works doesn’t mean it’s the best choice. Next time: I’ll research the functions and methods I’m using to see if it’s the best choice for my code.
   
3. Full-Time Developers Know A LOT. (and they don’t always agree) Almost every step along the way, the developers introduced me to syntax and logic that I hadn’t even considered when writing the code. I realized how powerful it is to get that many diverse perspectives in the same place to compare notes.
   
   The most interesting part of this was that they didn’t all agree on what the right choices were at each step. Everyone had their own preference that suited their coding style. Some developers had matter-of-fact answers that “method A” was demonstrably faster than “method B”, but another developer would come back with a rebuttal about readability or reuseability of code, or whether a specific method that was too obscure to be understood by most developers.
   
   The one thing they all agreed on: your indenting must be consistent! While there are different indenting and bracket placement preferences, this should be the same across your code.
   
   Next time: I hope to have more coding experience so I can be part of the debate!
   
4. Fewer Variables = Better. One of the best general comments I got was:
   
   Finding ways to eliminate variables or declare them as constants is almost always a good choice.
   
   Looking through my code, I realized I sometimes declare variables as a note to myself or clarification why a certain value goes in a specific function. I realized if I write better comments, I can fix this behavior and write cleaner code that doesn’t require extra variables, saving me the time when I come back to the code of having to figure out what those variables are doing, and why they are there. Next time: fewer variables!

This is a post I expect to come back to in the next few months as I work more on my C++ proficiency. I hope some of these notes are useful to you too!