My reading is that a formal code review is still focused on a single change, but with a more explicit/required process for review. This sentence in the article backs that up:

> Before any code at Google gets checked in, one owner of the code base must review and approve the change (formal code review and design inspection)

That's clearly referring to a specific change, not a review of the whole codebase.

I used to work for a large company. They have homegrown review software with extensive checklists of criteria the code must meet before it can pass review. The software won't let the code progress unless two reviewers go through and explicitly check off every box to certify it meets their standards. I'd call that formal code review.

I work on a smaller team now. We do consistently perform code reviews, but there's nothing actually preventing someone from merging without a review. We also have a list of things to look for when performing a code review, but nothing forces reviewers to look at the document regularly. That process is closer to an informal code review.

I still find bugs regularly when reviewing code. That's both true of other people's PRs as well as my own. I imagine there's a lot more variability with an informal process than a formal one, but IMO informal review is still useful. Code review of course also provides benefits other than bug detection.

I always review my own PR before passing it to someone else. Another commenter recommended that practice, and I heartily endorse it.