Code review is the process of inspecting software code to find and fix defects. A peer member of the development team examines the code, searching for potential problems and suggesting improvements.

This article will explore why you need good code reviews and how they work. We'll also cover code review best practices and learn how tools like Review Maps can help you visualize and better understand code changes—regardless of complexity.

Let's start with the fundamental question: Why is code review important?

The importance of code review

Code reviews help improve software quality by catching errors and potential problems within the application code before merging those code changes to the main branch of a repository. Code reviews also help ensure that all team members are familiar with the codebase and established coding standards.

Reviews can help to catch common coding errors and issues, leading to results that include:

  • Identifying bugs in the code
  • Enforcing code formatting standards
  • Improving modularization
  • Enforcing naming standards
  • Addressing inefficient variable usage to improve runtime memory footprint

By catching issues early, you can address them before they escalate into more significant problems. Consistent code review produces a consistent codebase, which is much easier to maintain later—even in the hands of an entirely new team of coders, testers, and reviewers. The process can also help developers learn from one another's mistakes, making it a powerful form of mentoring.

A properly implemented code review process can improve in-line documentation by encouraging developers to write clear, concise, and accurate comments and headers. Comments and headers that are well written and easy to follow will help other developers understand the code and its purpose; streamlining future modifications and additional features while avoiding errors.

Best practices

Ideally, your code review should take place before merging a feature branch into the main branch of the code's repository. This allows developers to catch and fix potential problems early in the development process. You can also perform code reviews during unit testing, functional testing, integration testing, and performance testing. Finally, code review is also a valuable tool for bug fixes.

How much code you should review depends on factors that include:

  • The size and complexity of the codebase
  • The experience level of the developers
  • The frequency of changes made to the codebase
  • The severity of potential defects in the code

Ultimately, deciding what and when to review your code will be the responsibility of your development teams. In the case of agile development, this may also depend on factors like sprint lengths.

Code review should be performed by someone familiar with the codebase. Ideally, it shouldn't be the person who wrote the code. As a rule, development team leads should be responsible for code reviews, while senior developers, CI administrators, and testers should be responsible for providing feedback.

Learn more in our detailed guide on creating a code review checklist

What should be reviewed?

First and foremost, code reviews should identify (and often address) any functional requirements lacking. The review should also identify any potential issues that could impact the functionality. It should verify the code follows a logical sequence and that there are no errors in the logic or algorithms.

Coding standards

Coding standards are guidelines that help developers create code that is consistent, reliable, and easy to read and maintain. Reviews should check for adherence to an organization's coding standards and suggest fixes if needed. In-line documentation must be consistent with the code and up-to-date and accurately describe the code's purpose.

Common coding issues

Reviews should look for instances of common coding malpractices such as:

  • Using hard-coded constants instead of referring to lookup sources
  • Potential infinite loops
  • Boundary conditions that can cause the code to take an unwanted path
  • Cases where important variables can accept null values
  • Lack of graceful exception handling
  • Insufficient or excessive logging
  • Inadvertent exposure of sensitive data

Too many occurrences of such problems can be signs of an unmanageable or non-scalable codebase.

Inconsistent formatting can make your code difficult to read and understand. Code reviews should look for consistent formatting for output, such as dates, status codes, and error messages.

Opportunities for refactoring

Refactoring is the process of improving the internal structure of a computer program without changing its external behavior. Refactoring aims to improve readability, maintainability, and flexibility. Reusability is the ability to use code in more than one place. Code reviews should involve looking for ways to refactor the code and improve its reusability.

In terms of security, code reviews should also involve looking for red flags, including:

  • Unsalted passwords
  • Weak input validation
  • Use of unsigned libraries (which could lead to the introduction of vulnerabilities)
  • Buffer overflows
  • SQL injections
  • Cross-site scripting

Specifically, you should look to answer questions like these:

  • Are all input parameters checked for validity?
  • Are there any potentially dangerous operations that can be compromised, such as file manipulations or network communications?
  • Is any sensitive data (such as authentication keys or passwords) stored or processed without proper encryption?
  • Is there proper authentication and authorization for actions like database access or file read/write?
  • Does the developer digitally sign the code?

Exception handling

Exception handling is another area where reviews should look for:

  • Multiple possible exception paths.
  • Error logging and alerting.
  • Correct and consistent use of return values.

Writing code reviews

When reviewing code, development teams should never forget that the code review process is meant to provide a positive learning experience and opportunity for growth for everyone. Teams should take their time and do a good job of it.

The more you can automate the review process, the more time you'll have to interpret and understand what it discovers. However, don't over-automate: an automated process that's too rigid may not allow the flexibility to accommodate different coding styles or changes.

The review process won't deliver much value if the development team doesn't consume it. The development team should read one another's comments, find a consistent mechanism for discussing issues (perhaps through interactive channels like Slack), and find opportunities to document their knowledge and new standards (for example, by using wikis or tools like Confluence).

Also, whenever possible, seek to avoid unnecessary blocking due to too many discussions, decision delays, or conflicts.

Handling pushback

It can be challenging to handle pushback on a contentious code review. One way to handle this is to reiterate the importance of the review and explain why you believe the changes are necessary. Specify if the issue raised was related to coding standards, a logic error, inefficient code, a security vulnerability, or lack of documentation. Where relevant, you can reference project documentation to strengthen your arguments.

You could also ask for suggestions on addressing the team's concerns. By remaining open and communicative, you may be able to resolve conflicts and continue working productively. Most of all, stay calm.

Introducing CodeSee Review Maps

Large codebases can be intimidating to review or understand, especially those new to the development team. Whether you're making your first pull request, hesitating before pushing a merge, trying to assess the status of your project, or starting a new review, quickly visualizing the complex layers and relationships can make a big difference.

CodeSee can give you that level of visualization. Specifically, Review Maps are powerful visualization and collaboration tools that can answer questions like what impact a planned change might have, what dependencies it may affect, or if there are edge cases that haven't yet been anticipated.

In summary

Writing, maintaining, and testing code requires serious skills, but it doesn't have to be complicated. Processes like code reviews and tools to automate them can make them simpler and more efficient.

As mentioned, CodeSee's Review Maps is one such tool. To see how it works, you can try it out.

💡
CodeSee offers a richer understanding of your codebase. Experience better code reviews and faster developer onboarding. Get started for free today.