Google's Engineering Practices - What to Look for in a Code Review

We learn what to look for in a code review while reviewing Google's engineering practices documentation as Michael relates patterns to choo-choos, Joe has a "weird voice", and Allen has a new favorite portion of the show.

Are you reading this via your podcast player? You can find this episode's full show notes at https://www.codingblocks.net/episode133 where you can also join the conversation.

Sponsors

• University of California, Irvine Division of Continuing Education – One of the top 50 nationally ranked universities, UCI offers over 80 certificates and specialized programs designed for working professionals. Registration is NOW OPEN! Sign up and reserve your seat today!
• Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after your first dashboard.

Survey Says

How likely are you to advocate for working from home in the future?

Take the survey at: https://www.codingblocks.net/episode133.

News

• Thank you to everyone that left us a review:
  • iTunes: codewith_himanshu, SpaceDuckets, akirakinski
  • Stitcher: Anonymous (from Croatia), Llanfairpwllgwyngyll (Wikipedia), Murali Suriar
• Watch Joe solve LeetCode Problems (YouTube)

Regarding the OWNERs file …

// TODO: Insert Clever Subtitle Here

Design

• This is the MOST IMPORTANT part of the review: the overall design of the changelist (CL).
• Does the code make sense?
• Does it belong in the codebase or in a library?
• Does it meld well with the rest of the system?
• Is it the right time to add it to the code base?

Functionality

• Does the CL do what it's supposed to do?
• Even if it does what it's supposed to do, is it a good change for the users, both developers and actual end-users?
• As a reviewer, you should be thinking about all the edge-cases, concurrency issues, and generally just trying to see if any bugs arise just looking at the code.
• As a reviewer, you can verify the CL if you'd like, or have the developer walk you through the changes (the actual implemented changes rather than just slogging through code).
• Google specifically calls out parallel programming types of issues that are hard to reason about (even when debugging) especially when it comes to deadlocks and similar types of situations.

Complexity

• This should be checked at every level of the change:
  • Single lines of code,
  • Functions, and
  • Classes
• Too complex is code that is not easy to understand just looking at the code. Code like this will potentially introduce bugs as developers need to change it in the future.

A particular type of complexity is o