Code Review Process: Best Practices

Systems that work heavily on coding applications are often overwrought with lines and paragraphs of syntactical and contextual language that can be tough to understand to the average pair of eyes.

Even more cumbersome and tiring is the process of debugging and looking for errors in the source code whenever some pesky errors arrive, or the results don’t match the expected output.

As technology undergoes an upheaval in the techniques and ideas used to uphold the tenants of advancement, so do the methods that are used to ensure that there is no room for errors and other discrepancies.

The code review process also referred to as peer review, stands out as a tried and tested method in a large palette of applications to allow for the systematic examination of software source code. It’s conducted to find bugs and improve the overall quality of the software.

The Roles Found In Code Review Process

There are at least two roles that are always present in a code review:-

• The author, who is responsible for creating the code being reviewed
• The reviewer, who is the person responsible for examining the code and reporting the results to the author.

The code review process can occur over a large network of programmers and debuggers or can be a shared task among a small group of developers. Often there is a particular platform or methodology(such as Agile) that runs in the background to ensure that the process yields reasonable results.

Examples Of Lightweight Techniques

• Over-the-shoulder
  • One developer looks over the author’s shoulder as the latter runs through the code and suggests changes to be made.
  • This method is more appropriate when dealing with short snippets, and extreme accuracy is required regarding the results.
• Email pass-around
  • As the name suggests, the author or the SCM system creates a hierarchical system and emails code to reviewers.
• Pair Programming
  • Two authors develop the source code together at the same workstation and reverse engineer the results with the assumption that they would arrive at the same base kernels.
• Tool-assisted
  • Obvious to the name, this means that authors and reviewers use specialised tools designed for peer code review.

[hubspot type=form portal=3432998 id=43c818e9-ba9d-4a5e-a027-8bf8aa4b4481]

Why The Code Review Process Matters

It’s a rather common question to come across. Why bother reviewing code? The benefits or the goals of the code review process well range in the following reasons:-

• Debugging
  • Finding bugs early before the deployment stage can save both time and money especially when they are at a stage when they are cheap to fix.
• Coding Standards Compliance
  • Code review helps to maintain consistent coding style across all company applications and respond faster to errors when any situations arise.
• Proliferating Knowledge
  • During the code review process, team members gain a better understanding of the code base and learn from each other while also correcting and edifying each other.
• Consistent Design And Implementation
  • A peer review process conducted with the objective to debug code helps to maintain a level of consistency in software design and implementation.
• Higher Software Security
  • Applications that require a high level of security are hugely benefited from targeted security reviews.
• Team Cohesion
  • Review discussions also save team members from isolation and equip them with a greater knowledge of each other’s skill-sets and weaknesses, becoming more responsive to greater issues and discrepancies.

• Confidence Of Stakeholders
  • Code review helps develop confidence in stakeholders about the technical quality of the execution of the project while also projecting a more refined image of the team in general.

The Basics Of The Code Review Process

• Review Less Than 400 Lines Of Code
  • According to a SmartBear study of a Cisco Systems programming team, the developers should review no more than 200 to 400 lines of code (LOC) at a time citing that the brain can only effectively process so much information at a time.
  • Say if a team decides to go beyond the 400 LOC limit, the ability to find defects is highly affected.
  • Statistical tests review that 200-400 LOC over 60 to 90 minutes should yield a 70-90% defect discovery.
• Take your Time And Plan Accordingly
  • It can be an intrusive thought to jump through the code and hope to find errors that perhaps someone could find as well in the next chain.
  • This does, however, produce a drop in defect density at rates faster than 500 LOC per hour. Code reviews in a reasonable quantity that occur at a slower pace for a limited amount of time results in the most effective code review.
• Keep A Time Limit Of 60 Minutes
  • Performance tends to suffer in a usual code review process after about 60 minutes. Studies show that taking breaks from a task over a period help maintain the flow of work without sacrificing much of it=s quality.
  • Conducting more frequent reviews should reduce the requirement to conduct a review of this length.
• Set Goals And Capture Metrics
  • Decide on how you will measure the effectiveness of peer review and name a few tangible goals.
  • Use the SMART criteria and start with external metrics. This is done to give you a quantifiable picture of how your code is improving.
• Lookout For The Key Metrics
  • Keep a close watch on internal process metrics such as inspection rate- the speed with which a review is performed., defect rate- the number of bugs identified per hour of review, defect density- the average number of bugs per line of code.
• Authors Should Annotate
  • Even before the review is initiated, authors should annotate code showing which files to look at first and to justify every source code modification.
  • Annotations should be directed at other reviewers to simplify and provide more context to the process.
• Use Code Review Checklists
  • Omissions can be the hardest defects to find because it´s difficult to review something that isn´t there.
  • Checklists help eliminate frequently made errors and deal with the challenges of omission finding.
  • Code review checklists also help members clear expectations for each type of review and can be helpful to find errors for reporting and process improvement purposes.
• Immediately Fix Defects Found
  • It’s common for many teams to lack a systematic method for fixing the bugs that they´ve worked so hard to find.
  • Always use a collaborative code review tool that allows debuggers to log bugs, discuss them with the author, and make approved code changes.
• Exploit And Use Collective Consciousness
  • The knowledge that others use to drive out errors and create better products is well contagious in the workplace.
  • Such an “ego effect” provokes developers to write cleaner code because their peers will certainly see it. Spot checking, for example, produced 20% to 33% of lower defect density with minimal time expenditure

• Practice Lightweight Code Reviews
  • If the tools don’t fit the team, they won’t fit the results. Using a lightweight, the tool-assisted process is recommended.
  • Lightweight code reviews take less than 20% the time of formal reviews and can find as many bugs as a formal review process. Such rigid procedures can at best consolidate work to six participants and hours of meetings paging through detailed code printouts.

• Always Leave Comments
  • Code review comments serve as the gateway or the language of communication between the programmer and the user. Even in a team of professionals proficient in coding, it is essential not to leave any second guesses of what the source code is and take some time to explain significant pieces.
  • This is especially useful when checking variables, values, function calls, loops and conditional statements.
• Decentralise All Information
  • All stakeholders must be on the same page when it comes to the code review process and would benefit if there is a uniform understanding of the source code, possible through sharing it with everyone.
  • If however there may be objections due to the confidential nature of certain data, then keep a separate team trusted to such access that can work on the bits and pieces alone.

Tools And Softwares For Code Review

• Collaborator
  • Collaborator is the most comprehensive peer code review tool useful when code quality is critical.
  • The tool allows for code change views, defects identification, comment additions as well as setting review rules and automatic notifications to ensure that reviews are completed on time.
  • It easily integrates with 11 different SCMs, as well as IDEs like Eclipse and Visual Studio.
  • Collaborator also allows teams to conduct peer code review document in the same tool improving alignment, design changes, and compliance burdens.
• Codebrag
  • Codebrag is a simple, light-weight, free and open source code review tool used for solving non-blocking code review, inline comments and likes, smart email notifications and so on.
  • Codebrag helps in delivering enhanced software that uses the agile code review methodology.
  • License for Codebrag is open source and is possessed by AGPL.
• Gerrit
  • Gerrit is a free web-based code review tool used for wither approving or disapproving code changes.
  • Gerrit can also be integrated with Git and provides repository management for Git.
  • Through the system, teams can use rationalised code review process and also take advantage of an extremely configurable hierarchy.
  • It’s more suitable for discussing a few detailed segments of the code with small changes to be made.
• Rhodecode
  • Rhodecode is an open source, protected and incorporated enterprise tool integrated to hold Git, Subversion, and Mercurial.
  • Rhodecode allows mainly for team collaboration, repository management, and code security. It has two editions, Community Edition (CE) which is a free and open source and the Enterprise Edition (EE) is licensed per user.
  • Its automation system makes workflows easier and faster to execute.
• Crucible
  • A web-based collaborative code review application excellent for finding defects, discussing the changes and sharing updates to all stakeholders.
  • Crucible fits perfectly for any structures pathway used in the code review process and for all kinds of team sizes.
  • It is a lightweight peer code review tool that is used in pre-commit and post-commit reviews.
  • It has capabilities for SVN, Perforce and CVS.
• Review Board
  • A web-based, collaborative, free and open source tool used for used by source team projects and companies.
  • Review Board can be integrated with ClearCase, CVS, Perforce and Plastic.
  • The Review Board tool has a coded syntax that is highlighted which makes it be read faster.
  • Review Board supports pre-commit reviews and post-commit reviews.
• JArchitect
  • JArchitect is a great tool for analysing Java code as after each review, and it surrenders a report stating the development of the project or software.
  • This easer the task of customising the code.
  • It is compatible with several CRMs, OS systems and plugins as well.
• Peer Review Plugin
  • A web-based environment that makes the code review user-friendly.
  • It allows coders to review the code during their own time and that too in a distributed fashion.
  • It is best suitable for reviewing files from the repository and commenting at the same time.

Questions To Consider When Code Reviewing

• Would the team be able to understand the code easily?
• Is the code written following the coding standards/guidelines?
• Has the same code been duplicated more than twice?
• Can the source code be unit tested or debugged easily to find the cause?
• Is any function or class too big? If yes, is the function or class having too many responsibilities?

Peer Code Review Best Practice

• Code formatting
  • While going through the code, interpret the code formatting to improve readability and make sure that the code is manifested from any sorts of blockers.
• Alignments
  • Use alignments (left margin) and proper white space to ensure that the code block starting and ending point are easily recognisable.
• Naming
  • Keep a steady watch that proper naming conventions are used and followed as per the review plan that is to be agreed upon by the entire team.
• Space Requirements
  • The code should fit with the standard 14-inch laptop screen.  There shouldn’t be a need to navigate horizontally as the code is interpreted faster when moving from top to bottom.
• Comments
  • While commented code should be kept, some can act as blockers and should be highlighted or removed if the comments are too large. Minimal commenting is to be used. The commented code can be obtained from Source Control (like SVN) if required.
  • Architecture
    
    • Split concerns into multiple layers and tiers as per requirements such as presentation, business and data layers.
    • Split the respective files as per the type such as HTML, JavaScript and CSS.
• • Coding Soft
    • No hard coding should be used with a heavier focus on constants and configuration values.
    • Group similar values under an enumeration (enum).
    • Avoid many multiple if/else blocks.
  • Testability
    • The code should have a refactor into a separate function (if required). Use interfaces while linking other layers as they can be copied easily.
    • Try to avoid static functions, single classes as these are not easily testable by mocks.
  • Debuggability
    • Provide support to log the flow, parameter data and exception details to find the cause easily.
    • For a Log4Net like component, add support for database logging by querying the log table.
  • Configurability
    • Keep the configurable values stored in places such as XML files and database tables so that no code changes take place.
  • Security
    • Take care of issues such as SQL injections and SSL breaches by doing a reverse DNS lookup.
    • Authentication, authorisation and input data validation against security threats such as cross-site scripting (XSS) should be done by encrypting any sensitive data.

Object-Oriented Analysis and Design Principles

According to the single responsibility principle (SRS), do not place multiple responsibilities into a single class or function and instead, refactor them into separate classes and functions.

Use the open-closed principle when adding new functionality or when existing code should not be modified. New functionality should be overwritten in new classes and functions.

Avoid lengthy interfaces and split them into smaller components based on the functionality. The interface should not contain any dependencies that are not a part of the expected functionality.

As a rule, do not hardcode the dependencies but inject them instead.

Closing Notes

The first step while assessing the code quality can be a hassle of great proportions that can be best dealt with using a static code analysis tool.

Use plugins such as SonarQube, NDepend, TFS and FxCop to get an in-depth analysis of the code. Resharper is another great plugin when dabbling with Visual studio.

To track the code review comments, conclude using tools like Crucible, Bitbucket and TFS code and complete review process.

What might seem like the trickiest and often the most laborious procedure of application development has to be cleaned and filtered for being usable. As such, always remember the importance of keeping the code reviewed and why it has to be done. Treat it not like a crucial step but an indispensable one. [hubspot type=form portal=3432998 id=43c818e9-ba9d-4a5e-a027-8bf8aa4b4481]