13 Code Review Standards Inspired by Google

In this article, we will briefly go through 13 code review standards that could dramatically help improve the health of your software as well as keep your developers happy.

Photo by NESA by Makers on Unsplash

In this article, we will briefly go through 13 code review standards that could dramatically help improve the health of your software as well as keep your developers happy.

As the name suggests,_ code review_ is a process where one or more developers review or screen the code written by another developer (the author) to ensure that:

• the code does not have any mistakes, and there are no bugs or issues
• it meets all the quality and styling guide requirements and standards
• the code does what it is intended to do
• when merged, it will leave the health of the codebase in a better state

This is why code review is a critical part of software development. The code reviewer is acting as the gatekeeper who decides whether the code is in a state to be part of the codebase and reach production.

Google is known for its technological excellence, and they have effective code review standards that seem to highlight some vital points to keep in mind when reviewing code. At Google,

“The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time.” — Google’s Engineering Practices documentation

Here is a list of things to keep in mind when you are reviewing a change list (pull request).

Code Review Standards

1. The code improves the overall health of the system

Every change list (pull request) improves the overall health of the system. The idea is that as a result of such small improvements, the health of the software or codebase will improve after every merge.

2. Quick code reviews, responses, and feedback

First and foremost, do not delay pushing (merging) better code. Don’t expect the code to be perfect. If it’s in a condition that improves the overall health of the system, then ship it.

“A key point here is that there is no such thing as ‘perfect’ code — there is only better code.”— Google’s Engineering Practices documentation

If you are not in the middle of a focused task, then do the code review shortly after it comes; however, one business day is the maximum time it should take to respond to a pull request (change list). It is expected for a change list (pull request) to get multiple rounds of partial/full code review in a single day.

3. Educate and inspire during the code review

Provide mentorship during code reviews by sharing knowledge and experience wherever possible.

4. Follow the standards when reviewing code

Always keep in mind that the style guide, coding standards, and such documents are the absolute authority during code reviews. For example, to enforce consistency between tabs vs. spaces, you can reference the coding conventions.

If Java is your language of choice, then you might find the following article useful that provides a summary of Java coding best practices at giant tech companies useful: “A Short Summary of Java Coding Best Practices.”

5. Resolving code review conflicts

Resolve conflicts by following the agreed-upon best practices in the style guide and coding standards documents as well as seeking the advice and suggestion of others who have more knowledge and experience in the area of the product.

Handle conflicts different based on the severity. Credit: Alex Hill

If your review comments are optional or minor, then clarify that in your review comments and leave it to the author to decide whether to address or ignore them.

As a code reviewer, you can at least suggest that the change list (pull request) remain consistent with the rest of the codebase in the absence of a style guide or coding standards.

6. Demo UI changes as a part of code review

If the change list (pull request) changes the user interface, then in addition to the code review, it’s necessary to have a demo to ensure that visually everything looks as expected and matches the mocks.

For the front-end change list (pull requests), it’s always recommended to do a demo/walkthrough or make sure that the change list also includes the necessary UI automation tests that verify the functionality added/updated.

7. Ensure that the code review accompanies all tests

Unless it’s an emergency, the pull request (change list) should accompany all the necessary tests, i.e., unit, integration, end-to-end, etc.

software-engineering coding startup technology programming

In this article, see if there are any differences between software developers and software engineers. What you’re about to read mostly revolves around my personal thoughts, deductions, and offbeat imagination. If you have different sentiments, add them in the comment section, and let’s dispute! So, today’s topic…

Software development is something that is gaining popularity at lightning speed with the development of technology. The demand for regular developers is high compared to most other mainstream professions. But, what are the other reasons for learning to code?

There is no better moment for me than starting a brand new project. Everyone is afraid of adding or removing stuff. I guess we all have known at least one project that anyone wants to touch, or heard the phrase:.

Why you’re likely wrong about what makes great programmers

To summarise the main differences between the software developer and engineer: A developer executes. ... So the software developer is mainly focused on developing code that is a part of software development cycle. An engineer designs and plans applying the principles of engineering to software development.