Google Engineering Practices Documentation
Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practices that we have developed over time. It is possible that open source projects or other organizations would benefit from this knowledge, so we work to make it available publicly when possible.
Currently this contains the following documents:
- Google’s Code Review Guidelines, which are actually two separate sets of documents:
- The Code Reviewer’s Guide
- The Change Author’s Guide
How to do a code review
The pages in this section contain recommendations on the best way to do code reviews, based on long experience. All together they represent one complete document, broken up into many separate sections. You don’t have to read them all, but many people have found it very helpful to themselves and their team to read the entire set.
- The Standard of Code Review
- What to Look For In a Code Review
- Navigating a CL in Review
- Speed of Code Reviews
- How to Write Code Review Comments
- Handling Pushback in Code Reviews
See also the CL Author’s Guide, which gives detailed guidance to developers whose CLs are undergoing review.
Terminology
There is some Google-internal terminology used in some of these documents, which we clarify here for external readers:
- CL: Stands for “changelist”, which means one self-contained change that has been submitted to version control or which is undergoing code review. Other organizations often call this a “change”, “patch”, or “pull-request”.
- LGTM: Means “Looks Good to Me”. It is what a code reviewer says when approving a CL.