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

+6  A: 

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

Robert Seder
Wouldn't the design review come first even before the developer starts writing code?
@CodeToGlory: depends on development style. In Cowboy, for instance, no way. :)
Code reviews can be done at any time (or not at all). So, first of all, the developer may have made decisions, but they weren't the best ones. Secondly, just because there was a design going in, doesn't mean it is still the best design, once coding has started. You may find out that there were some missing assumptions, which change the strategy.
Robert Seder
+3  A: 
  • Logic errors
  • Standards violations
  • Design flaws
  • etc
Can you give me some examples of standards violations that cannot be caught by fxcop?
@CodeToGlory: violating tax laws in a procedure that prints an invoice. AFAIK, there have been many attempts, but nobody has successfully embedded laws into a type system.
Jörg W Mittag
Likewise, HIPAA violations or similar.
+4  A: 

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).

C. Dragon 76
+2  A: 

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.]

Jörg W Mittag
+2  A: 

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. :(

Stephen Cleary
+2  A: 


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.

+1  A: 

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

Inelegant design.

Norman Ramsey