What can you catch in a manual code review that static code analysis tools cannot?

Question

What do you look for during code walkthroughs, inspections that regular static code analysis tools like FxCop, VS Code Analysis plugins cannot.

Answer 1

The main thing is really design approach. FxCop will cover syntax, and many of the main issues, but it won't tell you if there is a bad approach to a problem. The human developer that is doing the review can offer other ideas of solving the problem. So, I would argue that mandated FxCop is a huge step in the right direction (especially if you can enforce this) - but it doesn't eliminate the need to see if there is a better way to solve a problem. Hope that helps

Answer 2

• Logic errors
• Standards violations
• Design flaws
• etc

Answer 3

One sometimes under-appreciated aspect of code reviews is that the code reviewer becomes intimately familiar with source code he/she didn't write. So even if no changes are made as the result of a code review, there's still value in that two developers are now familiar with the code instead of just one. This benefit is especially realized when the original developer gets hit by a bus (or, more commonly, leaves the company or switches projects).

Answer 4

Here's a pretty simple example of something that pretty much none of the mainstream type systems or static analysis tools will catch but that is immediately obvious to any developer doing a code review:

proc subtract_two_numbers_from_each_other(a: num, b: num): num =
    return a + b

[Note: Pseudocode. Language doesn't really matter. Substitute any mainstream programming language you like.]

Answer 5

Code reviews would be useful for implementation fixes at a level not capable for static analysis tools. For example, a valid refactoring is to replace a lot of parameters with a parameter object; another valid refactoring is to replace a parameter object with individual parameters. Which one is correct is a matter of experience, the precise meanings of the parameters, and taste. So, code reviews act as a means for the "flavor" of a team to be universally applied to a code base. These types of fixes are at a level below design but above mechanics.

Another benefit of code reviews is language and library education. C# and the BCL are constantly evolving, and different programmers are aware of different benefits. For example, one programmer doing a code review may suggest the use of string.IsNullOrWhitespace in a particular situation where another programmer wasn't aware of that new method. This is something that static analysis tools can do, but they lack the personal interaction (and often the learning experience is lost). More complex examples are beyond the reach of current static analysis (e.g., recommending PLINQ instead of parallelizing by hand).

Sadly, I only imagine that these are benefits of code reviews. I've never seen one. :(

Answer 6

Easy.

Just look at all the code on StackOverflow where the reader response is "this is not the way to do it".

Try running fxcop on those and see if it complains.

Answer 7

What can you catch in a manual code review that static code analysis tools cannot?

Inelegant design.