views:

102

answers:

4

I'm using Visual Studio 2010, and in my C++/CLI project there are two Code Analysis settings:

  1. Enable Code Analysis on Build
  2. Enable Code Analysis for C/C++ on Build

My question is about the second setting.

I've enabled it and it takes a long time to run and it doesn't find much.

Do you recommend enabling this feature? Why?

+1  A: 

Never did anything for me. In theory, it's supposed to help catch logical errors, but I've never found it to report anything.

DeadMG
A: 

We are using LINT to do a static code analysis for plain C++ applications (no .Net, no C++/CLI). This is different from what you are using but probably the same principles can be applied.

We execute LINT like this:

  • During a build, only the changed sources (CPP files) are run through LINT. Possibly many more files are being recompiled (if a header file is changed), but only the changed .CPP files are run through LINT.
  • Run the static code analysis on all files on a Continuous Integration server. If it finds something, let it mail the error to the developers that most recently committed changes to the versioning system, or to the main developer.

What you could do additionally is to perform a static code analysis on all files that are committed to your versioning system. E.g. in Subversion you could do this in a commit-trigger.

Patrick
+2  A: 

The two options you specify control the automatic execution of Code Analysis on managed and native C++ respectively.

Code Analysis of managed code is performed by FXCop engine analyzing the generated IL.

Code Analysis of native code is performed during compilation by the PreFast engine analyzing the C++ source code.

I STRONGLY encourage you to require your developers to have run CA on their code BEFORE checking it in. If you don't, you're: 1) Delaying the process of ensuring that your code has no known vulnerabilities and issues that could otherwise have been systematically removed from your product's source.

2) Denying your developers their right to improve their skills by learning incrementally what code they should NOT be writing and why.

3) Selling your customers short because they're the ones who will suffer from crashes and security issues when they're using your product.

Further, if you're writing native C++ and have not already planned to start adorning your code with SAL Annotations, then, frankly, someone at your place of work deserves to be dragged out into the street and humiliated! There's some GREAT stuff coming down the pipe shortly in the next version of the SAL annotations - get on it now and be WAY ahead of the curve vs. your competitors! :)

bitcrazed
+1  A: 

CppDepend provides a console so you can integrate it to build process, you can query the code base with CQL and customize your output.

Issam