Static Analysis

In the Chapter 5, Coding Practices, there's a section on Code Reviews. Knowing that reviewers will find and fixate upon the simplest problems they can find, wouldn't it be great to remove all the trivial problems so that they're forced to look for something more substantial?

This is what static analysis does. It finds problems in code that can be automatically discovered without running the product, but that are either off-topic for compiler warnings or take too long to discover for the compiler to be an appropriate tool to search for them.

What are off-topic problems? Typically, those that require knowledge of the semantics of the functions or methods you're using – knowledge that's beyond the scope of the compiler. For example, consider a C++ destroyObject<T>(T t) function that deletes its parameter. Calling that function twice with the same argument would be an error – but the compiler doesn't know that if it's just inspecting the function signature. Others are a matter of style. For example, Apple's C APIs have a naming convention related to their memory management rules: a function name contains Create when the caller owns the returned object or Get when the callee does. It's not a mistake to use C language to mix those up, so the compiler won't tell you about it, but an analyzer can.

There is basically no reason to avoid using a static analyzer (if your reason is that there isn't one for your language/framework/whatever yet, you might have chosen a language/framework/whatever that isn't ready yet. There's a section about that in Chapter 12, Business). It'll discover easily fixable bugs for you and quickly train you into not making those mistakes in the first place.