Code Review - The Good, the Bad, and the Hard to Swallow.

“When you shoot an arrow of truth, dip its point in honey”

If I’m being honest I don't know anyone who likes code-reviews.

As a recipient of code reviews over my career, it’s hard for me to take the critique – It’s my code, I've invested time & effort (and sometimes tears) in it, and It's very hard to enjoy being proved wrong.

As a giver of code reviews, I understand the challenges – they are long and tedious, some might say boring and others might say useless

Code reviews can be tricky. On the one hand, they are essential for improving code quality and catching bugs early. On the other hand, they can be time-consuming and, for some people, anxiety-inducing. But fear not! With a few tips and tricks, you can become a master of the code review process.

First things first: what is a code review? At its simplest, a code review is a process in which one or more developers review another developer's code to check for errors, bugs, and other issues. Code reviews can be conducted in various ways, such as in-person meetings, email exchanges, or by using dedicated software tools.

Why are code reviews important? For starters, they can catch errors that might otherwise slip through the cracks, potentially causing problems down the line. Code reviews can also improve the overall quality of the code by encouraging best practices and highlighting areas for improvement. Additionally, code reviews can be an opportunity for knowledge sharing and collaboration among team members.

So far, so good. But what about the downsides of code reviews? It's no secret that some people find them stressful or frustrating. For developers, their code can feel like their "baby," and it can be tough to receive criticism or suggestions for improvement. For reviewers, the process can be tedious and require a keen eye for detail.

To make the most of the code review process, it's important to approach it with a constructive mindset. If you're the reviewer, start with a positive comment or two to set a positive tone. Then, be specific about what you like and don't like about the code, and explain why. Use "I" statements instead of "you" statements to avoid sounding accusatory. Provide suggestions for improvement, but leave it up to the code author to decide how to implement them. Don't nitpick minor style issues unless they are causing readability problems or are part of a team style guide.

If you're the author of the code being reviewed, try to approach the review with an open mind and a willingness to learn. Don't take feedback personally; remember that the goal is to improve the code, not to criticize you as a developer. Ask questions if you don't understand a reviewer's comments or suggestions. Consider implementing most or all of the reviewer's suggestions, but don't feel obligated to follow them blindly.

Respectful communication is key during code reviews. Try to use suggestive language that lets the other side feel like it's their own idea. Avoid phrases like "this is wrong" or "you should do it this way," which can come across as accusatory or directive. Instead, use phrases like "have you considered…" or "what if we tried…"

Code reviews can be a powerful tool for improving code quality and team collaboration. By following a few simple guidelines, you can make the most of the code review process and turn it into a positive experience for everyone involved. Here’s a preliminary guide to help reviewers create the most constructive process possible. Happy reviewing!

Steps for Conducting a Perfect Code Review

1.  Establish a Clear Process

The first step is to establish a clear review process that everyone on the team understands. This should include guidelines for submitting code for review, the roles and responsibilities of reviewers, and the expected timeframe for completing reviews.

2. Use Suggestive Language

When providing feedback during code reviews, it's essential to use suggestive language instead of directive language. This helps ensure that the developer doesn't feel attacked or defensive and is more likely to take the feedback constructively and implement the suggestions.

3.  Focus on High-Impact Issues

Reviewers should focus on high-impact issues during code reviews , such as security vulnerabilities or major bugs. This helps ensure that the most critical issues are addressed first, and the developer can prioritize their work accordingly.

4. Use Automated Tools

Using automated tools for code reviews, such as code analyzers or linters, can help identify issues quickly and accurately. This can save time and ensure that no critical issues are missed during the review process.

5. Check for Security Concerns

During code review, it's crucial to check for security concerns. Reviewers should look for potential vulnerabilities, such as SQL injection or Cross-Site Scripting (XSS), and suggest changes to mitigate these risks. They should also ensure that the code adheres to the project's security policies and standards.

‍

What are you looking for? the checklist:

1. Functionality: Does the code work as intended? Test it against expected behavior, edge cases, and potential pitfalls.
2. Readability: Is the code easy to read and understand? Consider naming conventions, function names, code structure, comments, and consistent formatting.
3. Maintainability: Can the code be easily maintained in the future? Look for modular design, low coupling, and high cohesion. Does the code contain any Magic Numbers? Should it? Does the code smell?‍
4. Performance: Are there any performance bottlenecks or areas for optimization? Check for inefficient loops, excessive memory usage, and suboptimal data structures.‍
5. Error Handling: Does the code handle errors and exceptions gracefully? Ensure that proper error messages and logging are in place. Look if any safety mechanism can be introduced to prevent the code from ‘throwing’ an error‍
6. Security: Are there any security vulnerabilities? Look for issues like SQL injection, cross-site scripting, or insecure data storage.‍
7. Scalability: Will the code perform well under increased load? Consider future growth and how it may affect the code's performance.‍
8. Documentation: Is the code well-documented? Check for clear, concise, and up-to-date comments and documentation.‍
9. Testing: Are there appropriate tests in place? Ensure that unit, integration, and functional tests are included and that they cover critical functionality.‍
10. Coding Standards: Does the code adhere to the team's or organization's coding standards and best practices? Ensure consistency with language-specific conventions and established guidelines. (Automation with linting tools modified to your team’s best practices can dramatically decrease related issues)

As developers, we have the responsibility to write the best code possible, and to help our fellow developers do the same. I hope that the tips above will help make your code review processes less painful, more constructive and encourage better coding practices.

‍

‍

Ariel Shadkhan is the Backend Team Lead at Enso Security, the first Application Security Posture Management (ASPM) tool used daily by AppSec teams to enforce, manage and scale a robust AppSec program, all without interfering with development. Questions and suggestions are welcome! Please reach out to Ariel at ariel@enso.security to get in touch.