13 code review criteria encouraged by Google

The article was shared from the public number: DevOps Cloud School

How to do a good job of code review

In this article, we'll outline 13 code review standards that can greatly help improve software health and keep developers happy.

As the name implies, code review is a process in which one or more developers review or filter code written by another developer (author) to ensure that:

• There are no errors or problems with the code.
• Meet all quality requirements and standards.
• The code performed the expected tests.
• When merged, it will keep the code base healthy better.

That's why code review is a key part of software development. Code reviewers act as code base administrators and are responsible for determining whether the code is in a state where it is to become part of the code base and go into production.

Google is known for its superior technology, which has effective code review standards that seem to highlight some of the key points to keep in mind when reviewing code. At Google, the primary purpose of code review is to ensure that the overall code health of Google's code base continues to improve over time.

This is the list of things you should keep in mind when viewing the change list.

Review criteria

1. This code improves the overall health of the system

Each Change List (Pull Request) improves the overall health of the system. The idea is that with such small improvements, the health of the software or code base improves with each merge.

2. Fast code review, response and feedback

First, don't delay pushing (merging) better code. D on't expect the code to be perfect. If its condition improves the overall health of the system, push.

"The key here is that there's no 'perfect' code, only better code."

If you are not in the middle of a priority task, check immediately after the code is complete; The change list is expected to receive multiple rounds of partial/complete code reviews within one day.

3. Educate and inspire during code review

Provide guidance during code review by sharing knowledge and experience as much as possible.

4. Follow the standards when reviewing code

Always keep in mind that coding standards such documents are the absolute authority during code review. For example, to maintain consistency between tabs and spaces, you can refer to encoding conventions.

5. Resolve code review conflicts

Resolve conflicts by following best practices agreed upon in style guidelines and coding standard documentation, and seeking advice from others with more knowledge and experience in the product area. Depending on the severity, conflict handling varies.

If your comments are optional or secondary, explain them in the comments, and then let the author decide whether to resolve or ignore them. As a code reviewer, you can at least suggest that the change list (request) be consistent with the rest of the code base without a style guide or coding standard.

6. Demonstrating UI changes is part of the code review

If The Change List (Pull Request) ChangeS The User Interface, In Addition To Code Viewing, You Must Demonstrate To Ensure That All SkinS On The Appearance Match ExpectationS And SimulationS.

For pull Request, it is always recommended to demonstrate/walk through, or to ensure that the change list also includes the necessary UI automation testing to verify the functionality of additions/updates.

7. Make sure that code review is accompanied by all tests

Unless in an emergency, pull requests (change lists) should be accompanied by all necessary tests, such as cell, integration, end-to-end, etc.

An emergency may be an error or security vulnerability that needs to be fixed as soon as possible, and you can add tests later. In this case, make sure that the appropriate issue is created and that someone has ownership immediately after completing a hot fix or deployment.

There is not enough reason to skip the test. If some goals are at risk of not being achieved due to time constraints, the solution is not to skip testing, but to scope deliverables.

8. Don't bother yourself with code reviews when you're focused

If you're in the middle of a priority, don't bother yourself, as it may take a long time to get back to normal. I n other words, interrupting dedicated developers can be much more costly than having them wait for code review. Code check after scheduled breaks (e.g. lunch, coffee, etc.).

Expectations are not always completed on the same day and the entire code review process is consolidated. I t is important to give the author some feedback quickly. F or example, you might not be able to do a full check, but you can quickly point out something that you can study. This will greatly reduce frustration during code review.

9. Review everything and don't make any assumptions

View each line of code assigned to you for inspection. Don't make assumptions about manually written classes and methods, and you should make sure you understand what the code is doing.

Make sure you understand the code you are checking. I f not, please clarify or request a code walkthrough/explanation. If you have some code that is not eligible for review, make sure that there are other qualified developers who can review those parts of the code.

10. Review the code with the overall picture in mind

Change is often helpful in a broader context. F or example, the file was changed and four lines of code were added. I nstead of looking at just four lines of code, consider looking at the entire file and checking for new additions. Do they degrade the quality of existing code, or do they make existing functionality a candidate for refactoring?

If you do not examine such simple additions in the context of a function/method or class, over time you will inherit a class that is uns maintainable, super complex, difficult to test, impossible to do, and difficult to extend or refactor.

Keep in mind that over time, few improvements add up to high-quality products with minimal defects, and as time goes on, minor code degradation or technical burdens can increase and make products difficult to maintain and scale.

11. Recognize and encourage good work during code review

If you see something nice in the change list, don't forget to call out the author's great work and encourage them. I t's something I've never done before. The purpose of code review should not only be to identify errors, but also to encourage and guide developers to do a good job.

12. Be careful, respectful, friendly, and clear in code review

It is important that you be kind, clear, polite, and respectful during code review, as well as be very clear and helpful to the author. When viewing code, be sure to comment on the code instead of the developer.

13. Explain your code review comments and keep the scope in mind

Whenever a code review suggests an alternative or tagging, it is important to explain why and provide examples based on your knowledge and experience to help developers understand how your recommendations will help improve code quality.

When recommending fixes or changes, find the right balance in how to guide the author in fixing the code. For example, I appreciate guidance, explanations, some tips or suggestions, not the entire solution.

That's what W3Cschool编程狮 has to say about the 13 code review standards that Google encourages.