26

I heard about Visual Studio's Code analysis but never used one. I've read MSDN, but still don't understand the real use of Code analysis.

Isn't it the same as StyleCop?

Somewhere, FxCop was also mentioned. What is the difference with Code analysis?

Do I need to use Code analysis for every project? Are code reviews done by my colleagues insufficient?

36

What is Code analysis?

Code analysis (previously FxCop) is a static analysis tool which searches for common patterns which may indicate that something is wrong in the source code. For example, if an instance of a class which implements IDisposable is not disposed properly, Code analysis will emit a warning:

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

This is the correct implementation of the previous piece of code:

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

As any static analysis tools, Code analysis is intended to find patterns which are cumbersome (or simply boring) to find manually. For instance, in the previous example, it may be quite boring for a developer to check if any class he uses implements IDisposable (or to remember all .NET Framework classes which implement it).

Which projects qualify?

Although it is subject to false positives, as any static analysis tools, it is usually beneficial to target zero warnings for business-critical code without using suppressions. Within Visual Studio, Code analysis can be configured to run at compile-time; if project settings also specify that warnings should be treated as errors, violations of Code analysis rules won't stay unnoticed.

Since static analysis can take some time for medium or large projects, it is often a good idea to move it from developer's machines to the TFS build server. While running Code analysis during pre-commit is not a good idea (unlike StyleCop), it can still run on build and fail it if warnings are found.

For non-business-critical code, Code analysis may be run manually from Visual Studio or command line. The checks and warnings can be fine-grained in project properties to suit your needs. For instance, globalization warnings can be turned off if your project is not intended to be localized.

As with StyleCop, it is essential to decide whether the project will target zero warnings from Code analysis from the beginning of the project. Introducing it in an existent project may be too painful.

Is it different from StyleCop?

Note that code analysis is not the same thing as StyleCop. The first difference is that Code analysis works with the compiled assembly, while StyleCop works with the source itself. The second (and most important) difference is that Code analysis searches for patters which may indicate a bug, while StyleCop is simply enforcing style rules—a simple convention used by your team.

Code analysis is also particularly useful for beginners who don't know the language very well, since it can often lead to "Aha!" moments. For example, CA2105: Array fields should not be read only may lead somebody to a discovery that even if an array is marked as read-only, it doesn't make it immutable, since nothing forbids to change the elements within the array. StyleCop don't lead to discoveries: there is nothing interesting in knowing that fields start with a lowercase letter or that local calls should be prefixed with this.

Even if some rules are enforced by both Code analysis and StyleCop (such as CA1707: Identifiers should not contain underscores vs. SA1310: Field names must not contain underscore), those two tools are complementary and often used side by side.

We already have code reviews

The presence of code reviews is not a reason to avoid Code analysis. Both Code analysis and StyleCop are excellent at finding things automatically before a code review. There is nothing worse than spending a code review pinpointing style problems or problematic patterns which could have been found automatically. Keep code reviews for interesting stuff.

Another aspect is that human reviewers are not necessarily good at spotting problems found by Code analysis. For instance, an instance of a class implementing IDisposable may be created in one location, and then disposed in a different location. It will take some time for a reviewer to find it, while it takes just a few milliseconds for a static analysis tool to discover it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.