Well, not to detract from your point (I agree), but what little research has been done in this area suggests that code reviews are actually one of the best ways to catch bugs: https://kevin.burke.dev/kevin/the-best-ways-to-find-bugs-in-...
I don't have "Code Complete" at hand to follow up on that, but I strongly suspect that the formal code review was defined in this research as reviewing the entire codebase line-by-line on meetings. As opposed to reviewing just a single change to the system.
Can you/anyone shed some light on this?
> 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.