Getty
Most tech leaders establish standardized code review processes for their dev teams. These processes generally include multiple rounds of review; in many cases, each team member is responsible for reviewing their own code as well as having another team member look it over. During code reviews, it’s essential to not only look for errors but also at how well the resulting product will function both now and in the future.
Since code review is as important a part of a developer’s job as writing code is, all tech pros need to know the best practices for conducting an effective, thorough analysis. Below, 16 industry leaders from Forbes Technology Council discuss their favorite strategies for reviewing code—strategies they ensure all their team members know and leverage.
1. Maintain High, Well-Defined Standards
As with any review process, it is important to maintain high and well-defined standards. Ease of reading and understanding must always exist so that any member of the team is able to perform a review, participate in co-authoring the code or carry out simple maintenance. On the other hand, having a good repository of reusable components is always worthwhile. - Miguel Llorca, Torrent Group
2. Review Code Soon After It’s Written
When reviewing code, there are a few practices that can make the process more effective. First, you should always be sure to review the code as soon as possible after it is written. This will help you catch problems with your own code before they become an issue for others on your team. - Leon Gordon, Pomerol Partners
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
3. Don’t Rush The Process
Don’t rush; it’s better to detect mistakes earlier than later. Keep your standards high, and remember Murphy’s Law—if anything can go wrong, it will. While reviewing the code, keep in mind that maintainability is as important as validity. And remember that you are part of the team and you are all working toward the same goal: the best quality product. - Klaudia Zaika, Apriorit LLC
4. Think About How An Attacker Could Misuse The Code
Beyond just thinking about and testing how the resulting application can be used, also think about how an attacker could misuse the code and exploit the users of the resulting application. With security vulnerabilities continuously being scanned and exploited out there, developers have an opportunity to build applications that are secure by design and be part of the solution. - Christine Bejerasco, WithSecure
5. Consider The Customer’s Perspective
We focus much more on delivering an incredible customer experience and less on code “unit tests.” Pretend you are the customer: Does your feature work as expected? How can you make it better? At the end of the day, the customer is what drives your business. If you keep them happy, you’re on the right track! - Adam Ayers, Number 5
6. Use A Diff Mechanism
One best practice is for the dev to proof their own code not by staring at a file in the integrated development environment but by using a Diff mechanism. Look at each code change and ensure it’s necessary. Too many times I’ve seen an unused import in a code Diff or a file with only white space changes—changes like that are easy to prevent. - Michael Nyman, iGrafx
7. Analyze Computational Complexity
In the context of code reviews for machine learning and artificial intelligence systems, the computational complexity of the code is particularly important. Understanding the runtime and memory complexity of the code, as well as the range of data sizes that the code is likely (and potentially) going to see, will help you avoid later memory or function time-out issues when it’s deployed on cloud and serverless systems. - Steven Gustafson, Noonum, Inc.
8. Use A Static Code Analyzer
Leverage a static code analyzer tool to perform the code review. There are many options available in the market where you can define the coding standards and your best practices in addition to the standard best practices that come as part of the tool. The tool will also uncover security vulnerabilities in the code and significantly reduce the time it takes for manual code review. - Selva Pandian, DemandBlue
9. Learn Your Team Members’ Most Common Mistakes
If you’ll be regularly working with the same group of developers and want to speed up code review, learn their most common mistakes. A majority of people who code have small habits that cause oddities in their work. If you can identify the quirks in each person’s coding style, you can save time and streamline the review process. - Thomas Griffin, OptinMonster
10. Look For Readability (And Nothing Else)
A simple rule I follow is to look for readability and nothing else. If I can’t figure out what the code is doing within about two minutes, I reject it. The rest of the aspects—formatting, logic, performance, testing, coverage and so on—are all really the author’s responsibility or are mostly covered by automated checks. The reviewer’s responsibility is to ensure it is readable and, hence, maintainable. - Ravi Ithal, Normalyze
11. Share Your Reasoning
When reviewing someone’s code, provide more feedback than “this is wrong” or “this is right.” Share your reasoning for what causes one thing to be “right” or “wrong.” People learn and can find similarities. So my suggestion is to give feedback with supporting information so the person receiving the feedback can actually learn to make good decisions in new cases, rather than just knowing “A is bad and B is good.” - Arturs Kruze, Magebit
12. Ensure The Process Is Blameless
It’s important for a code review process to be blameless. Reviews should be aimed at capturing the collective expertise of the team. The resulting code should reflect the best the team as a whole can create. A review process that does not place blame on the writer and a culture that is accepting of constructive criticism are key to getting this result. - Atul Tulshibagwale, SGNL.ai
13. Be Clear, And Document ‘Whys’
Clever code helps no one. We write code to be read by people, and something clever that is only understood by one person on the team will be impossible to fix later. If the code can’t be clear on its own with good naming conventions, make sure to document why the code exists, not what it is doing. You can always optimize later if the intent is clear, but no one can improve code they don’t understand. - Luke Wallace, Bottle Rocket
14. Leverage ‘Mob Review’
“Mob code reviewing” is the way to go. If code review is done by just one other person, it still leaves some room for error. In mob code reviewing, the whole team reviews the same piece of code at the same time. When you have multiple sets of eyes reviewing the same code, the chances of error are slim to none, especially while doing a pull request for production-level code. - Somdip Dey, Nosh Technologies
15. Let Users Test Function
Let actual users test it. Too often, software engineers work in a silo and discover bugs and functionality issues only after a software release is launched. By sharing a beta version with a small set of power users, software engineers will gain insights into user behavior that they themselves may otherwise not think of. - Roland Polzin, Wing Assistant
16. Compare Your Code To The ‘Best In Class’
Coding is best compared to creative writing. The best practice is to plan and write code while comparing it to the benchmark in its class. Just as there are different writing styles—business letters, novels or poetry—there are standards for each type of code being developed. Take the best in the particular class of code you’re writing and review your team’s code against that standard. - Blair Currie, Snibble Corp.
