Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 4, 2021
arrowPress Releases
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Opinion: The Benefits Of Code Review

Opinion: The Benefits Of Code Review

September 15, 2011 | By Lee Winder

September 15, 2011 | By Lee Winder
Comments
    1 comments
More: Console/PC, Programming



[In this reprinted #altdevblogaday-opinion piece, Blitz Game Studios' technical manager Lee Winder outlines why code reviews are important and how they can benefit your team for future projects.]

I am a big fan of code reviews, but they have a bad reputation. Worries about wasting time or getting bogged down in pointless and irrelevant discussions can cause the process to be dropped before it's even started.

So why am I such a fan?

Code Review Workshop

Sharing Experience And Knowledge

It might surprise you but this is one of the main reasons why I love code reviews. People learn best when they are surrounded by people they can learn from, and allowing those people to cast an eye over the code you are writing and talking about how something can be improved are invaluable.

Having people suggest different ways to structure, optimize, and write code might seem a little late when it's already written, but it's something people can take with them into their next task as they grow as developers.

And it works both ways too. Less experienced programmers might have their work discussed and improved, but it also allows them to question and push code from more experienced programmers who might be a bit more stuck in their ways than they should be.

Improving Code Quality

This sort of follows on from the above point, but as people are learning from each other, they are becoming better programmers. They are learning to avoid common mistakes, and as a result are writing more stable and easier to read code.

Programmers will also start to spend a little bit more time checking over the code they write. No one wants to put up a review only for someone to find a rookie mistake in the first five seconds, so small errors that in the past would have been checked in only to cause havoc later get found before the code is even committed.

Finding Bugs

It might just be me, but nearly every time I've asked someone to put up something for the first time, at least one bug is always found. It might be a misplaced define, a + instead of an â€", or any number of things but there's always one. And the time it took to post and complete that review will be much less than the time it takes for that bug to be found, a bug report written, the author to read the bug, find the code in question, do some tests, and then finally fix it.

But I generally find that the number of bugs found during code reviews starts to drop off over time. This isn't because people are getting lazy and not casting such a critical eye over the code but because the quality of the code is getting higher and higher.

As a result, all those bugs that might have otherwise found their way into the code base aren't even being added, let alone fixed early.

Sharing Domain Knowledge

The more people know about a particular system, the better. Illness, team moves, and resignations will always be part of the working environment, and it means that the key team member you are relying on could end up not being available when they are needed the most. And if you need someone else to dive in there and fix a couple of issues that have been found by QA, how long do you think that will take?

If a system has been constantly reviewed as it was developed, there will be a larger number of people who will feel comfortable getting stuck into that part of the code base.

Coding Standards

This is probably one of the main reasons people hate code reviews as they don't want every conversation to turn into a discussion about where the bracket should go or what pre-fix that variable should have on it.

How much of a problem this is depends on how strict your coding standards are and how by the book your code needs to be.

So it certainly has it's place in a code review.

Developers new to the team can be given documentation about coding standards, but it is one of those things that tend to easily slip, and there is no reason why this shouldn't be picked up in a review. Of course you need to be careful that your reviews don't start to get swallowed up in standards talk and the important elements like code quality start to suffer.

And There Will Be More

These are not the only benefits of code reviews, but to me they are the stand outs that make code reviews a vital part of the development process. Let me know if you have any more!

In the future, I'll look at some of the main reasons why code reviews can fail and why some teams will not get the benefits that they should be doing.

[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions. Image by Sebastian Bergmann. Used under license.]


Related Jobs

Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States
[08.03.21]

Data Engineer
Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States
[08.03.21]

Senior Gameplay Engineer
Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States
[08.03.21]

Senior Engine/Systems Engineer
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States
[08.03.21]

Tools Engineer









Loading Comments

loader image