In my Software Quality Assurance & Testing class, we recently did a group-based code review of a simple Sir Tommy Solitaire program that my professor wrote a few years ago. It was a really fun and interesting group activity that I enjoyed quite a bit, so I decided to look more into common Code Review practices to get a better understanding of how to conduct them in a better way. This article written by Trisha Gee I found on DZone.com was a great resource for learning more about them.
First and foremost, the most important thing to remember when conducting code reviews is that your job is to view the code within the parameters of the project you’re working on. For example, if your company uses Checkstyle and prefers Google Java Conventions vs Sun Code Conventions, then the team must keep that in mind when reviewing code. All reviews must be viewed through a lens that corresponds with the vision of the project at hand.
When you’re actually conducting the review, what are the easiest things to look for? The article from DZone mentioned these four topics:
- Formatting: Things line curly braces, spacing, line breaks.
- Style: Is the code laid out in a logical way (variable declarations near their usage, etc.)
- Naming: Are naming conventions upheld throughout the program? Are they descriptive enough?
- Test Coverage: Are there tests that cover the code and what it interacts with?
However, there are plenty of tools that exist to mitigate the potential errors which come from these easily spotted issues. Humans aren’t so great at noticing minute details — something that machines are perfect for. Formatting tools like Checkstyle that I referred to earlier will usually ensure that formatting standards are upheld, and tools like JaCoCo can assist test coverage (we’ve used both of these in class and it’s remarkable how helpful they are).
Really, the job of the reviewer is to focus more on the design choices and quality of the code. Not only should the code run, but it should be readable, maintainable, it should be written with good design principles in mind. Are any parts reused, are design patterns used in elegant ways or do they needlessly increase complexity?
I haven’t quite yet read through all of Clean Code by “Uncle Bob”, but from what I know it seems like many of the principles in that book are ones that should be deeply considered when conducting a code review. I think anyone looking for further elaboration on the topic of Code Reviews should read both the article I found on DZone (and other DZone material, frankly), and Clean Code — it’s as popular as it is for a reason.