Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to sabotage a code review

Martin Heller Owner, Martin Heller & Co.

What time is it, kids? It's code review time!

Code reviews are a black hole for your time. But by committing some common sins, you can make them completely useless, and perhaps get them dropped from your agile practices. Be prepared to sabotage the process with these eight handy antipatterns.

Come unprepared. Why should reviewing somebody else's crappy code take precedence over writing your own superb code? Does management have a policy in place about having to study the code before the review? Just lie about it: you needed some gym time much more than some code reading time.

Quibble over details. Since you didn't prepare, the easiest things to bring up in the review will be the ones that jump out at you on the screen. Is the code formatted using a different convention than what you use? Snipe about it. Are there some misspelled words in the comments? Obviously, that's worth mentioning. Go ahead—tie up six software engineers to haggle over grammar.

Make it personal. It's not enough to complain about trivia: you need to alienate the coder so that it will never happen again. Clearly, an engineer who doesn't understand your divinely inspired rule about where to put spaces, tabs, curly brackets, and newlines in JavaScript if-else clauses has demonstrated complete ignorance of all that is right and holy.

Ridicule the algorithms. Algorithms can always be improved—often immensely. It's rare, however, to see a professional code review in which someone implemented an O(n2) algorithm, such as a bubble sort for large lists in random order when an O(n log 2) algorithm (such as Quicksort) is readily available from the language library. That's a student/newbie mistake. Nevertheless, I'm sure you can dream up an unlikely edge condition for the algorithm used while you're enmeshed in the tedium of the code review, and then make your criticism completely and inappropriately scathing.

Demean the intentions. If the implementation looks OK, you can always claim that the intention of the code is misguided. "It appears to be a perfectly good MapReduce implementation, but wasn't the real intention to translate from Klingon to English? What idiot told you we needed this?" A word of caution here: if the "idiot" turns out to be your manager, this tactic might have unfortunate results.

Ask for more unit tests. You can never have enough unit tests. No matter how many have been presented for the purposes of the code review, you can always ask for more. "What do you mean, you thought you had 95 percent code coverage with your tests? Anything less than 100 percent coverage is completely unacceptable."

Say WTF. A lot. Every code review has its share of "WTF" comments; a few of these are expected. On the other hand, hearing a lot of WTF comments at a code review is usually a bad sign and gives off a bad code smell. Nobody will notice that all the WTF comments are coming from you if you throw your voice and imitate your colleagues.

All kidding aside, derailing a code review ultimately makes more work for everyone, including you. It can also poison the work environment for the whole team, not just the poor coder who bore the brunt of the criticism. Code reviews may not always be enjoyable, but they're necessary, and they can be useful when done with an eye toward being constructive and sharing hard-earned experience. If you see these negative behaviors in yourself, it's time for some soul searching. If this type of behavior is commonplace on your team, then it might be time to move on.

These are the worst of the worst behaviors I've seen. What's on your list?

Keep learning

Read more articles about: App Dev & TestingAgile