Dasch Fortner is giving you a glimpse into our apprentice program by writing about it bi-weekly. Check back in a few weeks to read more. Dasch is a junior computer science major at Cedarville University, and he isn’t particularly fond of long road trips. He says: “Honestly, if I wasn’t programming for school, I’d be programming for fun.”



Code Review = Whack-a-Mole?

“Why mod?” My teammate asked. “That just makes it random.”

I turned back to the computer screen to feast my eyes on an arithmetic expression that was fit for a meme. I had a misty memory of this code proceeding from my exhausted fingers during discouraged debugging.

“Wait, we don’t want it to be random,” my bewildered professor said. I didn’t want it to be, either. “Why are we doing that?”

“Well, it’s not exactly random,” my teammate remarked. “He’s passing that in as a parameter.”

“Hold on, let’s go through the calculation, because I’m not sure what’s going on there,” my professor said. I think he wanted to give me the benefit of the doubt.

We were doing a code review after working out some bugs for Cedarville’s ASEE robotics team. I had no defense. Within a function, I had written the instruction(0 – ts) % 5. The variable, ts, was a parameter to the function. I had hoped to convert ts to a small value with the opposite sign as ts. Since I was passing 255 in as ts, this beautiful string of wordiness evaluates to zero.

My time on Cedarville’s robotics certainly made me a better problem solver. Yet, as I looked through our code, I’m not sure my code had improved. Our program was full of commented-out code, rabbit-trails that we’d never plugged up. Variables had confusing or undescriptive names. Lots of functions we no longer (or never) used still loitered around in our program. After stepping back from the code for a month, it even had me scratching my head.

The first EduSource U was that Friday morning. As I scrolled through our code, I heard echoes of our discussion on the value of code review. I must confess, I wasn’t looking forward to code review during my first week. I felt like every addition to the code was just one more specimen to get scrapped in code review.

My first code review was a massive, multi-day behemoth – or, at least, so it felt to me. In the end I fixed over fifty issues. As someone who was new to code reviews, it was easy to feel overwhelmed and a little discouraged as your code was sifted through five lenses. Issues popped up quicker than I could resolve them. I felt like I was playing Whack-a-Mole, programmer’s edition.

Yet, as I took another look at our code from the robotics team I really understood that the code review process is worth it. While the robotics code wasn’t trash, it was extremely undisciplined. And after only a month of separation, it was a little confusing. Sure, our robot went around the track as it was supposed to. But, unfortunately, working code is not equivalent to good code. And if I had to maintain that program long-term, I think I might rip my hair out.