Code reviews: are they useful or a waste of time?

One of the most important skills of a developer is the ability to write clean code that is maintainable and error-free. No matter how skilled you are, it’s always possible that you’ll overlook certain bugs or potential problems in your code. The process of code review is coming up next.

Code reviews have become part of the software development process in many development companies and their purpose is to review code by teammates before it is committed to a source code repository in order to catch potential bugs, ensure adherence to coding standards, and last but not least, to share knowledge among team members.

Some people like them, others hate them. While some argue that code reviews are a necessary part of the development process, others question their effectiveness, calling them time-consuming and potentially redundant. The real benefits of code review are widely debated. So are code reviews really useful or are they just a waste of time? In our article, we look at the arguments of both camps.

Read also the article How to do effective code reviews: tips and tricks.

What is a code review?

Code review involves checking code written by one or more developers before merging it into a common source code repository. It is a systematic line-by-line review of source code by one or more people to find and correct errors, improve quality, and ensure compliance with coding standards.

It usually involves developers reviewing code changes made by their peers, providing feedback, suggesting improvements, and identifying potential problems. Code reviews can be performed using a variety of methods such as pair programming, email, in-person or online meetings, or using specialized tools that facilitate asynchronous reviews.

Code review process

In a code review, various aspects of the code are usually examined to ensure its quality and correctness. We provide a list of some of the main metrics that can be checked during the code review process:

Functionality: Verifies that the code correctly performs the required functions and operations. The code is checked to ensure that it addresses the requirements and ensures correct processing of data and inputs.

Efficiency and optimization: Code efficiency is checked and opportunities for optimization are sought. This may include changing algorithms, eliminating unnecessary repetition, or improving the performance of critical parts of the code.

Safety: The code is assessed for adherence to safety standards and policies. This includes preventing potential security vulnerabilities such as SQL injection, cross-site scripting (XSS) or unauthorized access.

Architecture and design patterns: Analyzes whether the code adheres to the design patterns and architectural principles used in the project. This aspect includes verifying that the code follows standard design rules for classes, modules and layers.

Readability: Measures how easy the code is to read and understand by other developers. This aspect includes important factors such as the use of understandable variables, correct and descriptive function names, and commenting out the less understandable parts of the code.

Coding style and conventions: Checks that the code follows the specified coding conventions and styles that are defined for the project or programming language. This aspect includes code formatting, the use of spaces, indentation, and so on.

Testing: Examines whether the code has been properly tested and whether tests have been written that cover all critical aspects of its functionality. This point also includes checking whether the new code hasn’t broken existing tests and whether it adds new testing scenarios.

Documentation: Assesses whether the code is adequately documented to make it easy to understand and use by other developers. This item includes code comments, documentation of the new API, and user guides.

Types of code review

Let’s now look at the various types of code checks used in companies.

In person (or by screen sharing via MS Teams)

This method is quite easy and convenient for most developers, and the developer gets feedback quite quickly. When your code is ready, you find an experienced teammate, make an appointment, and go through the code you’d like to commit to the repository together, in person or online. This type of code review is suitable for smaller changes, as the reviewer has less time to look at the code in peace.

E-mail thread

It solves the problem of finding a deadline for code review. Once a given piece of code is ready for review, the file (or a hyperlink to it) is emailed to the appropriate colleague(s) so that everyone can view it as soon as their work schedule allows. While this approach can certainly be more flexible and adaptable than more traditional techniques, such as a meeting of people focused on code review, an email thread with suggestions and differing opinions on how to fix code can quickly become bloated and it may not be obvious what has been fixed and what hasn’t yet been fixed.

Pair programming

Pair programming is an approach to software development where (most commonly) two developers work together on the same code, collaborating and mutually reviewing each other’s work. It’s a good way for senior developers to mentor younger colleagues and incorporate code review directly into the programming process. However, this code review approach loses the objectivity and unbiased approach of looking at and reviewing your own code. The biggest disadvantage, however, is the higher consumption of resources (especially staff and time) compared to other methods.

Software tools

They combine the advantages of the previous approaches and address many of the limitations of the previous approaches mentioned above, offering a simpler and more efficient way to inspect code. Code review can be done directly in the browser, or these tools can be seamlessly integrated into various development environments or code management tools via plugins.

They allow you to track peer comments and proposed defect solutions in a clear and coherent order (similar to tracking changes in MS Word), reviews are asynchronous (that is, based on who is available when), the author of the reviewed code receives notifications for new reviews.

There is no need to find an experienced colleague and arrange a date to check the code, people work on their machines and have as much time as they need to assess the correctness of the code. In addition, software tools have various built-in metrics for static code analysis that can alert the reviewer to specific parts of the code they should focus on in their review.

Benefits of code checks

Now let’s look at the arguments of both the proponents of code inspections and their opponents. Let’s start with the arguments that we will probably all agree with.

Two pairs of eyes see more than one.

We developers sometimes overestimate how good our code is, and a second independent view can give us a different perspective on our code and allow us to look at the code more objectively.

The reviewer can give us valuable feedback on how readable and understandable our code is. We usually try to write code so that when we come back to it after some time, we have no problem understanding how the code works and what it solves fairly quickly.

Knowledge sharing.

Code reviews provide an excellent opportunity to share knowledge among team members and learn something new. Whether it’s different coding styles, techniques and best practices, or the use of new frameworks and libraries, I personally see this cross-fertilization as the most significant benefit of the code review process.

Error detection

It is often mentioned as an advantage of code review that it is a form of bug detection and catching bugs before the code is used in a production environment will save time and resources in the long run. As a counterargument, however, it is noted that code should be functional and tested before code review.

Improved code quality

Another often mentioned benefit is improved code quality. Through constructive feedback and suggestions for improvements, code reviews help to improve the overall quality of the source code. But reviewers can also identify areas for optimization, code refactoring, or documentation improvement.

However, these advantages gradually disappear with the developer´s experience and a developer with many years of experience is able to identify these areas himself and take them into account when designing and implementing the solution.

Consistency of standards and procedures

Code reviews ensure consistency of standards and agreed coding practices across the team. This is true, but you can use various applications like Sonar to check this automatically, which eliminates the need to check it during code review.

Disadvantages of code checks

We come to the arguments of the opponents of conducting code reviews.

Lengthy, time-consuming and therefore expensive
And besides, code reviews are rarely fun. Therefore, especially under time pressure (which we all find ourselves under from time to time) or with a deadline fast approaching, they are either not done at all or at least occasionally skipped. This primarily applies to previously reviewed code, which should be rechecked whenever there’s any change made to it.

In addition, code review can be time-consuming, especially in large development teams or projects with large codebases. Thoroughly reviewing every line of code requires significant time and effort, which can slow down the development process.

Error-prone

They are prone to error because the reviewer is also only a human with more or less experience and in most cases not a security expert. Despite the best efforts of the reviewers, some issues may still slip through during code review. Human error, fatigue, or lack of expertise in certain areas can lead to critical issues being overlooked, reducing the effectiveness of the code review process.

Require at least two developers

They require at least two developers on the team who are familiar with the technology. The reviewer who checks the code should ideally have the same or higher level of experience because when a less experienced developer conducts a code review for a more experienced colleague, the entire code review process often loses its effectiveness.

Subjective and demotivating

Code reviews can sometimes be subjective, with different reviewers having different opinions on the quality and style of the code. This subjectivity often leads to conflicts or lengthy discussions within the team, which can delay the completion of the review and hinder productivity.

If the feedback is too critical or incorrectly given, the author of the code under review may feel demotivated. Similarly, if its code is not accepted into the repository after repeated checks and incorporation of feedback.

Software developers tend to love their own code more than anything else, and hate other developers’ code if it is written in a way they don’t like. They are quite sensitive about their code, and if someone points out that their code is bad, they associate that with them being bad developers.

Endless debates

Overall, code reviews often stimulate endless debates among developers. A developer can’t resist the temptation to prove to another developer that the way he/she writes code is incorrect. Developers usually do code reviews from their own perspective and don’t like to consider different approaches as correct. We prefer to believe that our approaches are just the right ones. This is explained by the fact that we as humans are too lazy and spending time and energy on solving an already solved problem is too painful for us.

Every developer wants to be acknowledged, so they present their arguments and use cases to convince the reviewer that their approach to solving the problem is better and more optimal. This leads developers into endless debates that ultimately harm both the company and its business.

Overthinking

Another problem that comes up in code review is overthinking. Even though the code may appear good at first glance, subconsciously, we want to find some flaw in it. We naturally feel good when we’re useful at something, and when we find a bug in the code, we feel useful.

Paradoxically, if we give the improved (corrected) code to the same reviewer to check it again, he will find more things to improve. Moreover, if we give the same code to another developer to check, he will find even more defects.

Conclusion

We’ve presented various perspectives on code reviews before committing, and it’s clear that they have many advantages and disadvantages. Ultimately, we leave it to the reader to judge which outweighs the other. However, if the code review process is not set up correctly, not enough time is allocated, or. code reviews are conducted under time pressure, and on top of that, if the reviewer doesn’t provide constructive feedback to the code author properly, it can significantly disrupt the team’s working atmosphere and lead to non-constructive arguments about whose problem-solving approach is better. That is why it is important to start trusting yourself more and letting others have the freedom to decide.

At msg life Slovakia we also use code reviews, but only for beginner developers. In this way, they can learn a lot through more experienced colleagues and get into a productive work process faster.

If you’re a Java developer looking for a job, check out our employee benefits and respond to our job offers.

About the author

Jozef Wagner

Java Developer Senior

Viac ako 10 rokov programujem v Jave, momentálne pracujem v msg life Slovakia ako Java programátor senior a pomáham zákazníkom implementovať ich požiadavky do poistného softvéru Life Factory. Vo voľnom čase si rád oddýchnem v lese, prípadne si zahrám nejakú dobrú počítačovú hru.