To make it natural for developers to use the analysis tool, it is fully integrated within the IDE. During the build process, any warnings generated for the source code appear in the Error List. These warnings include defect path information, if available; double-clicking the warning highlights the defect path that led to the warning.

Developers can use the #pragma directive to treat warnings as errors; and enable or disable warnings, as shown in the following examples:

#pragma warning (error: 6260)

#pragma warning (disable: 6011)

#pragma warning (enable: 6056)

Annotations improve the accuracy of the code analysis. Annotations provide additional information about pre- and post- conditions on function parameters and return types.

#include <CodeAnalysis/SourceAnnotations.h>

[returnvalue:Post( MustCheck=SA_Yes )] double* CalcSquareRoot

(

    [Pre( Null=SA_No )] double* source,

    unsigned int size

);

In the preceding example:

[Post ( MustCheck=SA_Yes)] requires caller to check the return value of CalcSquareRoot

[Pre ( Null=SA_No)] requires caller to pass non-null parameter "source" to CalcSquareRoot

As an organization, you might want to require that all check-ins satisfy certain policies. In particular, you want to make sure that you follow these policies:

1. There were no build errors in the code being checked in.

2. Code analysis was run as part of the most recent build.

You can accomplish this by specifying check-in policies.

You can use the integrated features of the build system to run the analysis tool as part of the build process. For more information, see Team Foundation Build Overview.

In addition to the full integration within the development environment, developers can also use the analysis tool from the command line, as shown in the following example:

C:\>cl /analyze Sample.cpp